US20180014346A1 - Apparatus and method for bidirectional ip flow mobility control - Google Patents
Apparatus and method for bidirectional ip flow mobility control Download PDFInfo
- Publication number
- US20180014346A1 US20180014346A1 US15/538,175 US201515538175A US2018014346A1 US 20180014346 A1 US20180014346 A1 US 20180014346A1 US 201515538175 A US201515538175 A US 201515538175A US 2018014346 A1 US2018014346 A1 US 2018014346A1
- Authority
- US
- United States
- Prior art keywords
- pgw
- flow mobility
- network
- initiated
- ifcp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H04W76/026—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/15—Setup of multiple wireless link connections
- H04W76/16—Involving different core network technologies, e.g. a packet-switched [PS] bearer in combination with a circuit-switched [CS] bearer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/18—Negotiating wireless communication parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/12—Setup of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
Definitions
- Embodiments of the present disclosure generally relate to the field of wireless communication, and more particularly, to apparatuses and methods for bidirectional IP flow mobility control.
- IP Internet Protocol
- NBIFOM Network based Internet Protocol
- PMIPv6 Proxy Mobile
- GPRS general packet radio service tunneling protocol
- S2a and S2b interfaces over wireless local area network
- WLAN wireless local area network
- FIG. 1 schematically illustrates a wireless communication system enabled to communicate with an IP Flow mobility Control Protocol (IFCP), in accordance with various embodiments.
- IFCP IP Flow mobility Control Protocol
- FIG. 2 is a schematic block diagram illustrating a user equipment (UE) and a Packet Data Network Gateway (PGW) enabled to communicate with the IFCP, in accordance with various embodiments.
- UE user equipment
- PGW Packet Data Network Gateway
- FIG. 3 is a flowchart illustrating a process for enabling IP flow mobility between a UE and a PGW, in accordance with various embodiments.
- FIG. 4 is a flowchart illustrating another process for enabling IP flow mobility between a UE and a PGW, in accordance with various embodiments.
- FIG. 5 is a flowchart illustrating yet another process for enabling IP flow mobility between a UE and a PGW, in accordance with various embodiments.
- FIG. 6 is a block diagram of an example computing device that may be used to practice various embodiments described herein.
- FIG. 7 illustrates an article of manufacture having programming instructions, incorporating aspects of the present disclosure, in accordance with various embodiments.
- Embodiments of the present disclosure describe apparatuses and methods for bidirectional Internet Protocol (IP) Flow Mobility (IFOM) control.
- Various embodiments may include a user equipment (UE) with signaling circuitry to establish a multi-access packet data network (PDN) connection with at least two radio access technologies to enable IP flow mobility based on the at least two radio access technologies.
- the UE may further include processing circuitry to control IP flow mobility between the UE and a Packet Data Network Gateway (PGW) based on a bidirectional signaling protocol that enables a coexistence of IP flow mobility initiated based on network policies and IP flow mobility initiated based on UE policies.
- PGW Packet Data Network Gateway
- the phrase “A and/or B” means (A), (B), or (A and B).
- the phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).
- the description may use the phrases “in an embodiment,” or “in embodiments,” which may each refer to one or more of the same or different embodiments.
- the terms “comprising,” “including,” “having,” and the like, as used with respect to embodiments of the present disclosure are synonymous.
- circuitry may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality.
- ASIC Application Specific Integrated Circuit
- processor shared, dedicated, or group
- memory shared, dedicated, or group
- module may refer to, be part of, or include an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
- ASIC application specific integrated circuit
- processor shared, dedicated, or group
- memory shared, dedicated, or group
- a module may be implemented in any combination of firmware and hardware.
- FIG. 1 schematically illustrates a wireless communication system 100 enabled to communicate with an IP Flow mobility Control Protocol (IFCP), in accordance with various embodiments.
- the wireless communication system 100 may include user equipment (UE) 110 , WLAN network 120 , cellular network 130 , PGW 140 , and access point name (APN) 150 to enable IP flow mobility, such as moving some IP flows from one path to another path within a multi-access packet data network (PDN) connection.
- IP flow mobility may be initiated, negotiated, and managed by a bidirectional signaling protocol that enables a coexistence of IP flow mobility initiated based on network policies and IP flow mobility initiated based on UE policies.
- Wireless communication technology may rely on various standards and protocols to transmit data between UE 110 and WLAN network 120 or cellular network 130 .
- Wireless communication system standards and protocols may include, for example, the 3GPP LTE; the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly known to industry groups as worldwide interoperability for microwave access (WiMAX); and the IEEE 802.11 standard, which is commonly known as Wi-Fi.
- IEEE Institute of Electrical and Electronics Engineers
- WiMAX worldwide interoperability for microwave access
- Wi-Fi Wi-Fi
- RAN radio access network
- LTE long term evolution
- the base station may be referred to as an evolved Node B (also commonly denoted as eNodeB, or eNB).
- eNodeB evolved Node B
- UE 110 may communicate with other devices via multiple radio access technologies.
- UE 110 may be a mobile communication device, a subscriber station, or another device that is configured to communicate with the WLAN network 120 and/or cellular network 130 , in conformance with an appropriate protocol (e.g., a multiple-input/multiple-output (MIMO) communication scheme).
- MIMO multiple-input/multiple-output
- UE 110 may access cellular network 130 via a radio link with a base station, e.g., an eNB 132 in cellular network 130 .
- a downlink (DL) transmission may be a communication from eNB 132 to UE 110 .
- An uplink (UL) transmission may be a communication from UE 110 to eNB 132 .
- WLAN network 120 may include various combinations of wireless personal area networks (WPANs), wireless local area networks (WLANs), wireless metropolitan area networks (WMANs), and/or wireless wide area networks (WWANs).
- the WLAN network 120 may provide an interface for apparatus 100 to operate on unlicensed spectrum with variants of IEEE 802.x-based radio access technologies, such as WiFi or WiMAX, to access at least one WLAN, as an example.
- WLAN network 120 may also enable apparatus UE 110 to communicate through short range wired or wireless communications such as IrDA, BluetoothTM, near field communications (NFC), Universal Serial Bus (USB), amongst others.
- WLAN network 120 may include Trusted Wireless Access Gateway (TWAN) 122 or Evolved Packet Data Gateway (ePDG) 124 .
- TWAN Trusted Wireless Access Gateway
- ePDG Evolved Packet Data Gateway
- Non-3GPP access may include access from Wi-Fi, WiMAX, etc., which may be trusted and/or untrusted non-3GPP access.
- Trusted Wi-Fi access may include an operator-built Wi-Fi access with encryption in the Wi-Fi radio access network (RAN) and a secure authentication method.
- UE 110 may connect through TWAG 122 to WLAN network 120 .
- TWAG 122 in turn may connect to PGW 140 in an Evolved Packet Core (EPC) through a secure tunnel (e.g., GTP, MIP, or PMIP).
- EPC Evolved Packet Core
- untrusted access may include other type of Wi-Fi access that does not provide sufficient security mechanisms such as authentication and radio link encryption.
- the untrusted model may require an Internet Protocol Security (IPSec) client in UE 110 .
- IPSec Internet Protocol Security
- UE 110 may connect to ePDG 124 through a secure IPSec tunnel.
- ePDG 124 in turn may connect to PGW 140 wherein each user session may be transported through a secure tunnel (e.g., GTP or PMIP).
- IPSec Internet Protocol Security
- the cellular network 130 may be connected to UE 110 and PGW 140 .
- the cellular network 130 may include one or more radio access networks, such as a Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Evolved HSPA (E-HSPA), or Long-Term Evolution (LTE) network.
- GSM Global System for Mobile Communication
- GPRS General Packet Radio Service
- UMTS Universal Mobile Telecommunications System
- High Speed Packet Access HSPA
- E-HSPA Evolved HSPA
- LTE Long-Term Evolution
- a radio access network may include GSM Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN).
- EDGE GSM Enhanced Data rates for GSM Evolution
- GERAN Universal Terrestrial Radio Access Network
- E-UTRAN Evolved
- cellular network 130 may include eNB 132 and serving gateway (SGW) 134 .
- SGW 134 may communicate with eNB 132 , e.g., over an S1 interface.
- the S1 interface may be similar to the S1 interface as defined in 3GPP TS 36.410 V11.1.0 (2013-September) and may support a many-to-many relation between SGW 134 and eNB 132 .
- different operators may simultaneously operate the same eNB in a network sharing setting.
- communication between eNB 132 and UE 110 may be facilitated via the SGW 134 .
- SGW 134 may be configured to manage signaling exchanges, e.g., authentication of UE 110 , or perform other actions associated with establishment of a communication link between UE 110 and PGW 140 .
- SGW 134 may be responsible for tracking and paging user equipment, e.g., when UE 110 is in an idle mode.
- the PGW 140 may provide a gateway for UE 110 to access many other packet data networks (e.g., Internet) from, e.g., UE 110 's mobile packet core network, such as cellular network 130 .
- packet data networks e.g., Internet
- per flow mobility in a multi-access PDN connection may be triggered by UE 110 or PGW 140 , using a bidirectional signaling protocol, such as the IFCP disclosed herein.
- the IFCP may be terminated in UE 110 or PGW 140 .
- IFCP messages may be transported at layer 3 over UDP/IP or TCP/IP.
- the IFCP protocol may be used after a multi-access PDN connection has been established (e.g., over 3GPP and WLAN accesses) in order to support UE-initiated and network-initiated IP flow mobility over a multi-access PDN connection.
- UE 110 may negotiate the NBIFOM capability with PGW 140 when a new PDN connection is established. UE 110 may transfer routing rules to PGW 140 and trigger UE-initiated IP flow mobility. UE 110 may accept or reject IP flow mobility request initiated by PGW 140 . UE 110 may notify PGW 140 when UE 110 is out of WLAN coverage and in turn suspend some flows. By the same token, UE 110 may notify PGW 140 when UE 110 is back in coverage and resume flows.
- PGW 140 may similarly negotiate the NBIFOM capability when a new PDN connection is established, trigger network-initiated IP flow mobility, and transfer routing rules to UE 110 . Further, PGW 140 may also accept or reject UE-initiated IP flow mobility.
- the underlying layer-2 links of a multi-access PDN connection between UE 110 and PGW 140 may be logically combined so that these layer-2 links may appear as a single interface to the IP protocol stack.
- PGW 140 may support the multi-access PDN connection to the same APN, such as APN 150 .
- APN 150 may identify the target PDN that UE 110 may target for communication. In addition to identifying the target PDN, APN 150 may define the type of service provided by the PDN, e.g. connection to Wireless Application Protocol (WAP) server and/or Multimedia Messaging Service (MMS). In various embodiments, APN 150 may include a gateway between a GPRS, 3G, or 4G mobile network and another computer network. As an example, APN 150 may be a Voice over LTE (VoLTE) APN. As another example, APN 150 may be a IP Multimedia Subsystem (IMS) Services APN. As yet another example, APN 150 may be a type of Voice over Data (VoD) Services APN. As yet another example, APN 150 may be an Internet APN.
- VoIP Voice over LTE
- IMS IP Multimedia Subsystem
- APN 150 may be a type of Voice over Data (VoD) Services APN.
- APN 150 may be an Internet APN.
- FIG. 2 is a schematic block diagram illustrating a UE and a PGW enabled to communicate with the IFCP, in accordance with various embodiments.
- the UE 210 may be similar to, and substantially interchangeable with, UE 110 of FIG. 1 .
- the PGW 220 may be similar to, and substantially interchangeable with, PGW 140 of FIG. 1 .
- UE 210 may include one or more antennas 218 and communication module 212 .
- communication module 212 may include signaling circuitry 214 and processing circuitry 216 as shown.
- signaling circuitry 214 may be in a separate module.
- processing circuitry 216 may be in a separate module.
- signaling circuitry 214 and processing circuitry may be in a separate module or may be both in different modules.
- the communication module 212 may be coupled with the antennas 218 to facilitate over-the-air communication of signals between UE 210 and other wireless devices.
- the signaling circuitry 214 may be configured to provide various signal processing operations on the signal to the antennas 218 with suitable characteristics.
- operations of the signaling circuitry 214 may include, but are not limited to, filtering, amplifying, storing, modulating, demodulating, and transforming, and like operations/processes, by way of example and not limitation.
- the UE 210 may include one or more antennas 218 to concurrently utilize radio resources of multiple respective component carriers.
- the UE 210 may be configured to communicate using orthogonal frequency division multiple access (OFDMA) (in, e.g., downlink communications) and/or single-carrier frequency-division multiple access (SC-FDMA) (in, e.g., uplink communications).
- OFDMA orthogonal frequency division multiple access
- SC-FDMA single-carrier frequency-division multiple access
- the UE 210 may use the signaling circuitry 214 to communicate with another UE via LTE ProSe or LTE Direct.
- the signaling circuitry 214 may be configured to receive signals from the antennas 218 , and then transmit the signals to other components of the UE 210 , for example, the processing circuitry 216 for internal processing.
- the processing circuitry 216 may enable IP flow mobility between UE 210 and PGW 220 based at least in part on an IFCP that enables a coexistence of UE-initiated IP flow mobility and PDN-GW-initiated IP flow mobility with a multi-access packet data network (PDN) connection.
- PDN packet data network
- the processing circuitry 216 of the UE 210 may send an IFCP capability request, regarding the type of network based IP flow mobility (NBIFOM) capability supported by the PGW, to the PGW 220 , and the PGW 220 may send a response to the UE 210 where the response provides information about the capability of the PGW 220 .
- the processing circuitry may receive an IFCP capability request, regarding the type of NBIFOM capability supported by the UE 210 , from the PGW 220 , and the UE 210 may send a response to the PGW 220 where the response provides information about the capability of the UE 210 .
- the processing circuitry 216 may receive an IFCP mode request from the PGW to indicate a mode of operation for IP flow mobility for Network-initiated IP flow mobility.
- the processing circuitry 216 may send an IFCP mode request to the PGW to indicate a mode of operation of IP flow mobility for UE-initiated IP flow mobility.
- the processing circuitry 216 may receive an IFCP mode response from the PGW to indicate a mode of operation of IP flow mobility for UE-initiated IP flow mobility.
- the processing circuitry 216 may send an IFCP mode response to the PGW to indicate a mode of operation for IP flow mobility for Network-initiated IP flow mobility.
- the processing circuitry 216 may send an IFCP suspend request to the PGW to suspend the multi-access PDN.
- the processing circuitry 216 may send an IFCP resume request to the PGW to resume the multi-access PDN.
- the processing circuitry 216 may receive an IFCP flow mobility request to negotiate routing rules between the UE and the PGW.
- the processing circuitry 216 may transmit an IFCP flow mobility request to negotiate routing rules between the UE and the PGW.
- the processing circuitry 216 may receive an IFCP flow mobility response to negotiate routing rules between the UE and the PGW.
- the processing circuitry 216 may transmit an IFCP flow mobility response to negotiate routing rules between the UE and the PGW.
- the processing circuitry 216 may prioritize Access Network Discovery and Selection Function (ANDSF) rules over RAN rules for routing traffic.
- the processing circuitry 216 may prioritize Network-initiated routing rules over UE-initiated routing rules.
- ANDSF Access Network Discovery and Selection Function
- the UE 210 may be, may include, or may be included in a single sensor device, a cellular telephone, a personal computer (PC), a notebook, an ultrabook, a netbook, a smartphone, an ultra mobile PC (UMPC), a handheld mobile device, a universal integrated circuit card (UICC), a personal digital assistant (PDA), a Customer Premise Equipment (CPE), a tablet computing device, or other consumer electronics such as MP3 players, digital cameras, and the like.
- PC personal computer
- UMPC ultrabook
- UICC ultra mobile PC
- UICC ultra mobile PC
- UICC universal integrated circuit card
- PDA personal digital assistant
- CPE Customer Premise Equipment
- tablet computing device or other consumer electronics such as MP3 players, digital cameras, and the like.
- the UE 210 may include a mobile station, as defined by IEEE 802.16e (2005 or 802.16m (2009) or some other revision of the IEEE 802.16 standard, or user equipment, as defined by 3GPP LTE Release 8 (2008), Release 9 (2009), Release 10 (2011), Release 12 (2014), Release 13 (under development), or some other revision or release of the 3GPP LTE standards.
- IEEE 802.16e 2005 or 802.16m (2009) or some other revision of the IEEE 802.16 standard
- user equipment as defined by 3GPP LTE Release 8 (2008), Release 9 (2009), Release 10 (2011), Release 12 (2014), Release 13 (under development), or some other revision or release of the 3GPP LTE standards.
- PGW 220 may include control module 222 and communication module 224 , coupled with each other, to manage Internet Protocol (IP) flow mobility between the UE 210 and the PDN-GW based at least in part on a user plane bidirectional signaling protocol that enables a coexistence of a PDN-GW-initiated IP flow mobility type and a UE-initiated flow mobility type.
- IP Internet Protocol
- communication module 224 may include an S2 interface 226 and an S5/S8 interface 228 to communicate with communication networks with different radio technologies.
- PGW 220 may include S2 control and data plane stacks to support the S2 interface 226 (e.g., including S2a or S2b interface) to communicate with, e.g., TWAN 122 or ePDG 124 of FIG. 1 .
- PGW 220 may include S5/S8 control and data plane stacks to support S5/S8 interface 228 to communicate with, e.g., SGW 134 of FIG. 1 .
- the integrated control/data plane stacks for S5/S8 interface 228 may include IP, UDP, eGTP-C, etc.
- IFCP messages may be transported via S2a interface (e.g., via GTP or PMIPv6) or an S2b interface (e.g., via GTP or PMIPv6) through a WLAN network between UE 210 and PGW 220 .
- IFCP messages may be transported via an S5 interface through a cellular network between UE 210 and PGW 220 .
- IFCP may impact only UE 210 , PGW 220 , and the Policy Control and Charging Rules Function (PCRF) (not shown), e.g., when dynamic Policy and Charging Control (PCC) is deployed.
- PCRF Policy Control and Charging Rules Function
- the IP address of PGW 220 may be provided to UE 210 during PDN connection establishment.
- IFCP may use IPSec or Datagram Transport Layer Security (DTLS) for security between UE 210 and PGW 220 .
- DTLS Datagram Transport Layer Security
- FIG. 3 is a flowchart illustrating a process for enabling IP flow mobility between a UE and a PGW, in accordance with various embodiments.
- the process 300 may be performed by a UE, e.g., UE 110 of FIG. 1 or UE 210 of FIG. 2 .
- the process 300 may enable a UE to utilize the IFCP to manage IP flow mobility.
- the process 300 may include, at 310 , enabling IP flow mobility between a UE and a PGW based at least in part on an IFCP that enables a coexistence of UE-initiated IP flow mobility and Network-initiated IP flow mobility with a multi-access packet data network (PDN) connection.
- PDN packet data network
- the IFCP may enable a co-existence mechanism between Network (PCC/PCRF Rules) and Client (ANDSF, RAN rules) initiated IP Flow Mobility triggers and policies.
- the IFCP may enable a UE and a PGW to negotiate and exchange routing filters between the UE and the PGW.
- IP flow mobility may be initiated based on network policies (PCC/PCRF rules) or based on client policies such as (ANDSF or RAN rules) to support network based flow mobility.
- triggers for IP flow mobility may be initiated in the UE and the network.
- the IFCP disclosed herein may provide such a mechanism for co-existence between these scenarios so that conflicts may be resolved and different deployment scenarios may be supported.
- the IFCP may be supported at the layer 3 over UDP/IP or TCP/IP.
- the UE or PGW may notify the peer entity (e.g., PGW/UE respectively) of a change in IP flow routing preference via the IFCP.
- This user plane signaling solution may enable IP flow mobility by only impacting a small number of entities, for example, UE, P-GW and PCRF and without affecting other network entities (e.g., MME, S-GW, TWAG, ePDG, AAA server and corresponding protocols (GTP-C, EAP, WLCP, IKEv2 and NAS)).
- the IFCP may also enable WLAN to signal a switch in the routing of an IP flow from a failing cellular connection to WLAN when using S2a Spatial Channel Module (SCM), which is problematic in the existing control plane signaling approach.
- SCM Spatial Channel Module
- the process 300 further may include, at 320 , receiving or transmitting (sending) an IFCP capability request or response between the UE and the PGW to indicate NB-IFOM capability supported by the UE or the PGW.
- IFCP messages of IFCP Capability Request/Response may be used to query a UE or a PGW for their NB-IFOM capability.
- the UE or the PGW may check for support of Network Based IP Flow Mobility (NBIFOM) with the other peer, which responds with a Boolean NBIFOM Capability Support indicating whether NBIFOM Capability is supported or not. Therefore, the UE and the PGW may communicate their respective NBIFOM capability.
- NBIFOM Network Based IP Flow Mobility
- FIG. 4 is a flowchart illustrating another process 400 for enabling IP flow mobility between a UE and a PDN Gateway (PGW), in accordance with various embodiments.
- the process 400 may be performed by a UE, e.g., UE 110 of FIG. 1 or UE 210 of FIG. 2 .
- the process 400 may enable a UE to utilize the IFCP to manage IP flow mobility.
- the process 400 may include, at 410 , receiving or transmitting (sending) an IFCP mode request or response between the UE and the PGW to indicate a mode of operation as the UE-initiated IP flow mobility or the Network-initiated IP flow mobility.
- IFCP messages of IFCP Mode Setup Request/Response may be used to setup either the UE Mode or Network mode of operation.
- the UE may set the UE mode of operation wherein UE initiates changes in routing rules.
- the PGW may accept/reject the rules and vice versa for Network mode of operation initiated by the PGW.
- the process 400 may further include, at 420 , receiving or transmitting (sending) an IFCP flow mobility request or response to negotiate routing rules between the UE and the PGW.
- IFCP messages of IFCP Flow Mobility Request/Response may be used by the UE or the PGW to send routing rules to the peer in a IFCP Flow Mobility request message, and the peer may respond in Response Code in IFCP Flow Mobility Response message whether the routing rules may be accepted.
- a routing rule may include various parameters, such as routing filter, routing access information, routing rule priority, routing rule identifier, etc.
- a routing filter may include IP header parameter values/ranges used to identify one or more IP flows.
- the routing access information may identify the access type where the IP flow shall be routed.
- the filters may be applied in the order of the routing rule priority.
- the routing rule identifier may uniquely identify a routing rule for one PDN Connection.
- the routing rule identifier may be allocated by the entity creating the routing rule, e.g., by the UE in UE-initiated NBIFOM mode and by the PGW in a Network-initiated NBIFOM mode.
- the routing rule information may be encapsulated in PCO datatype.
- the process 400 may further include, at 430 , transmitting (sending) an IFCP suspend/resume request to the PGW to suspend/resume the multi-access PDN.
- the UE may transmit (send) a suspend request (e.g., as illustrated at Table 7) to the PGW to suspend specific PDN connections.
- the PGW may send a suspend response (e.g., as illustrated at Table 8) to the UE to respond to the suspend request.
- the UE may send a resume request (e.g., as illustrated at Table 9) to the PGW to resume specific PDN connections.
- the PGW may send a resume response (e.g., as illustrated at Table 10) to the UE to respond to the resume request.
- FIG. 5 is a flowchart illustrating yet another process 500 for enabling IP flow mobility between a UE and a PDN Gateway (PGW), in accordance with various embodiments.
- the process 500 may be performed by a PGW, e.g., the PGW 140 of FIG. 1 or PGW 220 of FIG. 2 .
- the process 500 may include, at 510 , managing Internet Protocol (IP) flow mobility between a UE and the PGW based at least in part on a user plane bidirectional signaling protocol (e.g., the IFCP) that enables a coexistence of a Network-initiated IP flow mobility type and a UE-initiated flow mobility type.
- the IFCP may enable a UE or a PGW to use a single procedure/message to move multiple IP flows.
- the IFCP may enable a UE or a PGW to negotiate, accept, or reject routing rules.
- the IFCP may enable a UE or a PGW to transfer routing rules over any target network, including S2a SCM or a network utilizing PMIP.
- the IFCP may reduce overhead when a PGW allows IFCP traffic on an NBIFOM PDN connection and may take this into account for its charging and usage monitoring counters.
- the IFCP may enable a UE or a PGW to use IPSec or DTLS to counter any security impacts to prevent a malware from attacking the IFCP stack in the PGW.
- the process 500 may further include, at 520 , using the user plane bidirectional signaling protocol to negotiate a plurality of parameters of the Network-initiated IP flow mobility type or the UE-initiated flow mobility type between the UE and the PGW when the UE establishes a multi-access PDN connection to the PGW.
- UE-initiated NBIFOM may co-exist with Network-initiated NBIFOM.
- IP Flow mobility may be initiated based on network policies (for example, PCC/PCRF rules) or based on client policies (for example, ANDSF or RAN rules) to support network-based flow mobility.
- network policies for example, PCC/PCRF rules
- client policies for example, ANDSF or RAN rules
- Corresponding triggers for IP flow mobility may be initiated in the UE and the network.
- the IFCP may provide a mechanism for co-existence between these scenarios so that conflicts can be resolved and different deployment scenarios can be supported.
- 3GPP Rel-12 solution based on RAN rules specifies that APN-level offloading and mobility may be done on a per PDN Connection granularity.
- the UE moves the offloadable PDN connections from 3GPP to WLAN.
- the MME/SGSN indicates, via NAS signaling, the PDN Connections that are offloadable to WLAN.
- the RAN may be oblivious regarding which mobility solution is used and whether PDN level mobility or flow level mobility is used.
- NBIFOM it is not clear how RAN rules that govern PDN level mobility may affect flow level mobility.
- the IFCP provides a co-existence mechanism in conjunction with PCC/PCRF rules for NBIFOM.
- the granularity for deciding what traffic may be offloaded to WLAN may be set on IP Flow level.
- the per RAT WLAN offloadability indication per PDN Connection may be used for NBIFOM PDN connections as well.
- ANDSF rules may have preference (or priority) over RAN rules. If no ANDSF rule is present, then RAN rules may be used. ANDSF rules may always be used in roaming scenarios. In some embodiments, traffic may be routed to WLAN only if both client and network rules to move traffic to WLAN are satisfied. Otherwise, traffic may be routed on 3GPP access only, such as illustrated in the routing rule negotiation items of Table 11.
- a choice may be made between only allowing the UE to initiate IP flow mobility (UE-controlled mode) or only allowing the network to initiate IP flow mobility (NW-controlled mode).
- UE-controlled mode IP flow mobility
- NW-controlled mode IP flow mobility
- the UE may request UE-controlled mode during IFCP session setup. If the UE does not request UE-controlled mode, the network may inform the UE that NW-controlled mode will be used.
- the UE can use the ANDSF routing rules or RAN rules when the UE-controlled mode is negotiated. When the NW-controlled mode is negotiated, the UE does not use any ANDSF routing rules or RAN rules (it uses the network-provided rules instead).
- a UE may request UE Mode of operation, and the network may accept that request. If no network rules apply, then the UE mode of operation may be selected. In some embodiments, network may have PCC or PCRF rules. Network may request NW mode of operation, and UE may accept that. If no UE rules are provided, then a Network mode of operation may be selected. In some embodiments, if both a UE and a Network have rules, the Network may gain precedence over the UE, and NW mode of operation may be selected. In some embodiments, the selected rules may be applied based on the agreed mode of operation, and the IP Flow routing may be selected accordingly.
- IP flow routing may include one or more options.
- the ANDSF rules may take priority of the RAN rules.
- the UE may request a UE mode of operation for IP flow routing to the network. If the network does not have IP flow routing rules, the network may accept the UE request and confirm that IP flow routing is to be performed using the UE mode of operation for IP flow routing. If the network does have IP flow routing rules, the network may reject the UE request and may make a network request to the UE to use the network rules for IP flow routing, and the UE may accept that request.
- the network may make a request for IP flow routing based on network rules.
- the UE may accept the request and use the network rules. If both the UE and the network have IP flow routing rules, the network rules may take priority over the UE rules.
- FIG. 6 illustrates, for an embodiment, an example system 600 comprising radio frequency (RF) circuitry 610 , baseband circuitry 620 , application circuitry 630 , memory/storage 640 , display 650 , camera 660 , sensor 670 , and input/output (I/O) interface 680 , coupled with each other at least as shown, which may be used to implement UE 110 , PGW 140 of FIG. 1 or UE 210 , PGW 220 of FIG. 2 .
- RF radio frequency
- the application circuitry 630 may include circuitry such as, but not limited to, one or more single-core or multi-core processors.
- the processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.).
- the processors may be coupled with memory/storage 640 and configured to execute instructions stored in the memory/storage 640 to enable various applications and/or operating systems running on the system 600 .
- the baseband circuitry 620 may include circuitry such as, but not limited to, one or more single-core or multi-core processors.
- the processor(s) may include a baseband processor.
- the baseband circuitry 620 may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 610 .
- the radio control functions may include, but are not limited to, signal modulation, encoding, decoding, radio frequency shifting, etc.
- the baseband circuitry 620 may provide for communication compatible with one or more radio technologies.
- the baseband circuitry 620 may support communication with an EUTRAN and/or other WMAN, a WLAN, or a WPAN.
- Embodiments in which the baseband circuitry 620 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.
- baseband circuitry 620 may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency.
- baseband circuitry 620 may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.
- the processing circuitry 216 or 226 of FIG. 2 may be embodied in the application circuitry 630 and/or the baseband circuitry 620 .
- RF circuitry 610 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium.
- the RF circuitry 610 may include switches, filters, amplifiers, etc., to facilitate the communication with the wireless network.
- RF circuitry 610 may include circuitry to operate with signals that are not strictly considered as being in a radio frequency.
- RF circuitry 610 may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.
- the signaling circuitry 214 or 224 of FIG. 2 may be embodied in the RF circuitry 610 .
- the constituent components of the baseband circuitry 620 , the application circuitry 630 , and/or the memory/storage 640 may be implemented together on a system on a chip (SOC).
- SOC system on a chip
- Memory/storage 640 may be used to load and store data and/or instructions, for example, for system 600 .
- Memory/storage 640 for one embodiment may include any combination of suitable volatile memory (e.g., dynamic random access memory (DRAM)) and/or non-volatile memory (e.g., flash memory).
- suitable volatile memory e.g., dynamic random access memory (DRAM)
- non-volatile memory e.g., flash memory
- the I/O interface 680 may include one or more user interfaces to enable user interaction with the system 600 and/or peripheral component interfaces to enable peripheral component interaction with the system 600 .
- User interfaces may include, but are not limited to, a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc.
- Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.
- USB universal serial bus
- sensor 670 may include one or more sensing devices to determine environmental conditions and/or location information related to the system 600 .
- the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit.
- the positioning unit may also be part of, or interact with, the baseband circuitry 620 and/or RF circuitry 610 to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.
- GPS global positioning system
- the display 650 may include a display, e.g., a liquid crystal display, a touch screen display, etc.
- the camera 660 may include many molded plastic aspheric lens elements made with varying dispersion and refractive indexes. In some embodiments, the camera 660 may include two or more lenses to capture three-dimensional images for stereo photography.
- system 600 may be a mobile computing device such as, but not limited to, a smartphone, a tablet computing device, a netbook, an ultrabook, a laptop computing device, etc.
- system 600 may have more or fewer components, and/or different architectures.
- FIG. 7 illustrates an article of manufacture 710 having programming instructions, incorporating aspects of the present disclosure, in accordance with various embodiments.
- an article of manufacture may be employed to implement various embodiments of the present disclosure.
- the article of manufacture 710 may include a computer-readable non-transitory storage medium 720 where instructions 730 are configured to practice embodiments of or aspects of embodiments of any one of the processes described herein.
- the storage medium 720 may represent a broad range of persistent storage media known in the art, including but not limited to flash memory, dynamic random access memory, static random access memory, an optical disk, a magnetic disk, etc.
- computer-readable storage medium 720 may include one or more computer-readable non-transitory storage media.
- computer-readable storage medium 720 may be transitory, such as signals, encoded with instructions 730 .
- instructions 730 may enable an apparatus, in response to its execution by the apparatus, to perform various operations described herein.
- storage medium 720 may include instructions 730 configured to cause an apparatus, e.g., UE 110 of FIG. 1 or UE 210 of FIG. 2 , to practice some aspects of IP flow mobility control, e.g., as illustrated in process 300 of FIG. 3 or process 400 of FIG. 4 , in accordance with embodiments of the present disclosure.
- storage medium 720 may include instructions 730 configured to cause an apparatus, e.g., PGW 140 of FIG. 1 or PGW 220 of FIG. 2 , to practice some aspects of IP flow mobility control, e.g., as illustrated in process 500 of FIG. 5 , in accordance with embodiments of the present disclosure.
- a first kind of examples may include an apparatus, such as a user equipment (UE), which may include signaling circuitry to establish a multi-access packet data network (PDN) connection with at least two radio access technologies to enable Internet Protocol (IP) flow mobility based on the at least two radio access technologies; and processing circuitry, coupled to the signaling circuitry, to control IP flow mobility between the UE and a PDN Gateway (PGW) based on a bidirectional signaling protocol that enables a coexistence of IP flow mobility initiated based on network policies and IP flow mobility initiated based on UE policies.
- PDN packet data network
- PGW PDN Gateway
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the bidirectional signaling protocol is terminated at the UE and the PGW, and the processing circuitry is to negotiate routing rules between the UE and the PGW using the bidirectional signaling protocol over Transmission Control Protocol (TCP)/IP or User Datagram Protocol (UDP)/IP.
- TCP Transmission Control Protocol
- UDP User Datagram Protocol
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the signaling circuitry is to exchange routing rules between the UE and the PGW based on the negotiation.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the processing circuitry is to use the bidirectional signaling protocol to negotiate Network-based IP flow mobility (NB-IFOM) capability between the UE and the PGW when the multi-access PDN connection is established.
- NB-IFOM Network-based IP flow mobility
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the processing circuitry is to use the bidirectional signaling protocol to trigger UE-initiated IP flow mobility and negotiate routing rules based on the network policies and the UE policies.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the processing circuitry is to use the bidirectional signaling protocol to accept or reject network-initiated IP flow mobility and negotiate routing rules based on the network policies and the UE policies.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the at least two radio access technologies comprises a WiFi technology to access a wireless local area network (WLAN), wherein the processing circuitry is to notify the PGW using the bidirectional signaling protocol when the UE is out of the WLAN, and request the PGW to stop sending downlink packages over the WLAN to the UE.
- the at least two radio access technologies comprises a WiFi technology to access a wireless local area network (WLAN)
- the processing circuitry is to notify the PGW using the bidirectional signaling protocol when the UE is out of the WLAN, and request the PGW to stop sending downlink packages over the WLAN to the UE.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the processing circuitry is to notify the PGW using the bidirectional signaling protocol when the UE is back in the WLAN, and request the PGW to resume sending downlink packages over the WLAN to the UE.
- a second kind of examples may include a method, comprising: enabling IP flow mobility between a UE and a PDN Gateway (PGW) based at least in part on an IP Flow mobility Control Protocol (IFCP) that enables a coexistence of UE-initiated IP flow mobility and Network-initiated IP flow mobility with a multi-access packet data network (PDN) connection; and receiving or sending an IFCP capability request or response between the UE and the PGW to indicate a type of IP flow mobility (NB-IFOM) capability supported by the UE or the PGW.
- IFCP IP Flow mobility Control Protocol
- NB-IFOM IP flow mobility
- Another example may include the method of any of the preceding second kind of examples, and the method further include receiving or sending an IFCP mode request or response between the UE and the PGW to indicate a mode of operation as the UE-initiated IP flow mobility or the Network-initiated IP flow mobility.
- Another example may include the method of any of the preceding second kind of examples, and the method further include sending an IFCP suspend request to the PGW to suspend the multi-access PDN; and sending an IFCP resume request to the PGW to resume the multi-access PDN.
- Another example may include the method of any of the preceding second kind of examples, and the method further include receiving or sending an IFCP flow mobility request or response to negotiate routing rules between the UE and the PGW.
- Another example may include the method of any of the preceding second kind of examples, and the method further include prioritizing Access Network Discovery and Selection Function (ANDSF) rules over Radio Access Network (RAN) rules for routing traffic; or prioritizing Network-initiated routing rules over UE-initiated routing rules.
- ANDSF Access Network Discovery and Selection Function
- RAN Radio Access Network
- Another example may include an apparatus comprising means to perform any of the preceding second kind of examples.
- Another example may include one or more non-transitory computer readable media comprising instructions to cause an apparatus, upon execution of the instructions by one or more processors of the apparatus, to perform any of the preceding second kind of examples.
- a third kind of examples may include an apparatus, such as a packet data network gateway (PGW), which may include a communication module to communicate with a UE via a multi-access packet data network (PDN) connection; and a control module to manage Internet Protocol (IP) flow mobility between the UE and the PGW based at least in part on a user plane bidirectional signaling protocol that enables a coexistence of a Network-initiated IP flow mobility type the and a UE-initiated flow mobility type.
- PGW packet data network gateway
- IP Internet Protocol
- control module is to use the user plane bidirectional signaling protocol to negotiate a plurality of capability parameters of the Network-initiated IP flow mobility type or the UE-initiated flow mobility type between the UE and the PGW when the UE establishes the multi-access PDN connection to the PGW.
- Another example may include the apparatus of any of the preceding third kind of examples, wherein the control module is to use the user plane bidirectional signaling protocol to accept or reject a UE-initiated IP flow mobility session.
- Another example may include the apparatus of any of the preceding third kind of examples, wherein the control module is to use the user plane bidirectional signaling protocol to trigger a Network-initiated IP flow mobility session and transfer routing rules based on network policies to the UE.
- a forth kind of examples may include a method, comprising: managing Internet Protocol (IP) flow mobility between a UE and the PGW based at least in part on a user plane bidirectional signaling protocol that enables a coexistence of a Network-initiated IP flow mobility type and a UE-initiated flow mobility type; and using the user plane bidirectional signaling protocol to negotiate a plurality of capability parameters of the Network-initiated IP flow mobility type or the UE-initiated flow mobility type between the UE and the PGW when the UE establishes a multi-access PDN connection to the PGW
- IP Internet Protocol
- Another example may include the method of any of the preceding forth kind of examples, and the method further include using the user plane bidirectional signaling protocol to trigger a Network-initiated IP flow mobility session based on Policy and Charging Control (PCC) or Policy and Charging Rule Function (PCRF).
- PCC Policy and Charging Control
- PCRF Policy and Charging Rule Function
- Another example may include the method of any of the preceding forth kind of examples, and the method further include using the user plane bidirectional signaling protocol to accept or reject a UE-initiated IP flow mobility session.
- Another example may include the method of any of the preceding forth kind of examples, and the method further include routing traffic via a WLAN only if the PGW and the UE agree on a WLAN based routing rule based on the user plane bidirectional signaling protocol.
- Another example may include the method of any of the preceding forth kind of examples, and the method further include prioritizing Network-initiated routing rules over UE-initiated routing rules.
- Another example may include the method of any of the preceding forth kind of examples, and the method further include transferring Network-initiated routing rules to the UE using the user plane bidirectional signaling protocol.
- Another example may include the method of any of the preceding forth kind of examples, and the method further include receiving an IFCP flow mobility request or send an IFCP flow mobility response to negotiate routing rules between the PGW and the UE.
- Another example may include an apparatus comprising means to perform any of the preceding forth kind of examples.
- Another example may include one or more non-transitory computer readable media comprising instructions to cause an apparatus, upon execution of the instructions by one or more processors of the apparatus, to perform any of the preceding forth kind of examples.
Abstract
Embodiments of the present disclosure describe apparatuses and methods for bidirectional IP flow mobility control. Various embodiments may include a UE with signaling circuitry to establish a multi-access packet data network (PDN) connection with at least two radio access technologies to enable Internet Protocol (IP) flow mobility based on the at least two radio access technologies. The UE may further include processing circuitry to control IP flow mobility between the UE and a PDN Gateway (PGW) based on a bidirectional signaling protocol that enables a coexistence of IP flow mobility initiated based on network policies and IP flow mobility initiated based on UE policies. Other embodiments may be described and/or claimed.
Description
- The present application claims priority to U.S. Provisional Patent Application No. 62/105,456, filed Jan. 20, 2015, entitled “NBIFOM CONTROL PROTOCOL AND SUPPORT FOR CO-EXISTENCE MECHANISMS,” the entire disclosure of which is hereby incorporated by reference in its entirety for all purposes.
- Embodiments of the present disclosure generally relate to the field of wireless communication, and more particularly, to apparatuses and methods for bidirectional IP flow mobility control.
- The background description provided herein is for generally presenting the context of the disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art or suggestions of the prior art, by inclusion in this section.
- The 3rd Generation Partnership Program (3GPP) Release-13 (Rel-13) Service & System Aspects (SA) work item number 2 (SA2) on Network based Internet Protocol (IP) flow mobility (NBIFOM) defines the IP flow mobility functionality for Proxy Mobile (PM) IPv6 (PMIPv6 or PMIP) and general packet radio service (GPRS) tunneling protocol (GTP)-based S2a and S2b interfaces over wireless local area network (WLAN). So far, moving individual IP flows belonging to the same packet data network (PDN) connection across different accesses (e.g., 3GPP access and WLAN access) may be done only by using client-based IP Flow Mobility (IFOM) Management protocols such as DSMIPv6.
- Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.
-
FIG. 1 schematically illustrates a wireless communication system enabled to communicate with an IP Flow mobility Control Protocol (IFCP), in accordance with various embodiments. -
FIG. 2 is a schematic block diagram illustrating a user equipment (UE) and a Packet Data Network Gateway (PGW) enabled to communicate with the IFCP, in accordance with various embodiments. -
FIG. 3 is a flowchart illustrating a process for enabling IP flow mobility between a UE and a PGW, in accordance with various embodiments. -
FIG. 4 is a flowchart illustrating another process for enabling IP flow mobility between a UE and a PGW, in accordance with various embodiments. -
FIG. 5 is a flowchart illustrating yet another process for enabling IP flow mobility between a UE and a PGW, in accordance with various embodiments. -
FIG. 6 is a block diagram of an example computing device that may be used to practice various embodiments described herein. -
FIG. 7 illustrates an article of manufacture having programming instructions, incorporating aspects of the present disclosure, in accordance with various embodiments. - Embodiments of the present disclosure describe apparatuses and methods for bidirectional Internet Protocol (IP) Flow Mobility (IFOM) control. Various embodiments may include a user equipment (UE) with signaling circuitry to establish a multi-access packet data network (PDN) connection with at least two radio access technologies to enable IP flow mobility based on the at least two radio access technologies. The UE may further include processing circuitry to control IP flow mobility between the UE and a Packet Data Network Gateway (PGW) based on a bidirectional signaling protocol that enables a coexistence of IP flow mobility initiated based on network policies and IP flow mobility initiated based on UE policies. These and other aspects of the present disclosure will be more fully described below.
- In the following detailed description, reference is made to the accompanying drawings, which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure.
- Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiment. Various additional operations may be performed and/or described operations may be omitted in additional embodiments.
- For the purposes of the present disclosure, the phrase “A and/or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). The description may use the phrases “in an embodiment,” or “in embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous.
- As used herein, the term “circuitry” may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality.
- As used herein, the term “module” may refer to, be part of, or include an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. In various embodiments, a module may be implemented in any combination of firmware and hardware.
-
FIG. 1 schematically illustrates awireless communication system 100 enabled to communicate with an IP Flow mobility Control Protocol (IFCP), in accordance with various embodiments. Thewireless communication system 100 may include user equipment (UE) 110,WLAN network 120,cellular network 130, PGW 140, and access point name (APN) 150 to enable IP flow mobility, such as moving some IP flows from one path to another path within a multi-access packet data network (PDN) connection. Further, such IP flow mobility may be initiated, negotiated, and managed by a bidirectional signaling protocol that enables a coexistence of IP flow mobility initiated based on network policies and IP flow mobility initiated based on UE policies. - Mobile communication technology may rely on various standards and protocols to transmit data between UE 110 and WLAN
network 120 orcellular network 130. Wireless communication system standards and protocols may include, for example, the 3GPP LTE; the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly known to industry groups as worldwide interoperability for microwave access (WiMAX); and the IEEE 802.11 standard, which is commonly known as Wi-Fi. In a 3GPP radio access network (RAN), according to long term evolution (LTE), the base station may be referred to as an evolved Node B (also commonly denoted as eNodeB, or eNB). Although the present disclosure is presented with terminology and examples generally directed toward 3GPP systems and standards, the teachings disclosed herein may be applied to any type of wireless network or communication standard. - UE 110 may communicate with other devices via multiple radio access technologies. In some embodiments, UE 110 may be a mobile communication device, a subscriber station, or another device that is configured to communicate with the
WLAN network 120 and/orcellular network 130, in conformance with an appropriate protocol (e.g., a multiple-input/multiple-output (MIMO) communication scheme). As an example, in various embodiments, UE 110 may accesscellular network 130 via a radio link with a base station, e.g., an eNB 132 incellular network 130. A downlink (DL) transmission may be a communication from eNB 132 to UE 110. An uplink (UL) transmission may be a communication from UE 110 to eNB 132. - In various embodiments,
WLAN network 120 may include various combinations of wireless personal area networks (WPANs), wireless local area networks (WLANs), wireless metropolitan area networks (WMANs), and/or wireless wide area networks (WWANs). TheWLAN network 120 may provide an interface forapparatus 100 to operate on unlicensed spectrum with variants of IEEE 802.x-based radio access technologies, such as WiFi or WiMAX, to access at least one WLAN, as an example. In some embodiments,WLAN network 120 may also enable apparatus UE 110 to communicate through short range wired or wireless communications such as IrDA, Bluetooth™, near field communications (NFC), Universal Serial Bus (USB), amongst others. - In various embodiments,
WLAN network 120 may include Trusted Wireless Access Gateway (TWAN) 122 or Evolved Packet Data Gateway (ePDG) 124. Non-3GPP access may include access from Wi-Fi, WiMAX, etc., which may be trusted and/or untrusted non-3GPP access. Trusted Wi-Fi access may include an operator-built Wi-Fi access with encryption in the Wi-Fi radio access network (RAN) and a secure authentication method. In some embodiments, UE 110 may connect through TWAG 122 toWLAN network 120. TWAG 122 in turn may connect to PGW 140 in an Evolved Packet Core (EPC) through a secure tunnel (e.g., GTP, MIP, or PMIP). - In various embodiments, untrusted access may include other type of Wi-Fi access that does not provide sufficient security mechanisms such as authentication and radio link encryption. The untrusted model may require an Internet Protocol Security (IPSec) client in UE 110. UE 110 may connect to ePDG 124 through a secure IPSec tunnel. ePDG 124 in turn may connect to PGW 140 wherein each user session may be transported through a secure tunnel (e.g., GTP or PMIP).
- The
cellular network 130 may be connected to UE 110 and PGW 140. In various embodiments, thecellular network 130 may include one or more radio access networks, such as a Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Evolved HSPA (E-HSPA), or Long-Term Evolution (LTE) network. In some embodiments, a radio access network may include GSM Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). Thecellular network 130 may operate in accordance with other network technologies in other embodiments. In various embodiments,UE 110 may use an interface to communicate withcellular network 130 on licensed spectrum with cellular radio access technologies, such as CDMA, WCDMA, UMTS, GSM, or LTE. - In various embodiments,
cellular network 130 may includeeNB 132 and serving gateway (SGW) 134. In some embodiments,SGW 134 may communicate witheNB 132, e.g., over an S1 interface. The S1 interface may be similar to the S1 interface as defined in 3GPP TS 36.410 V11.1.0 (2013-September) and may support a many-to-many relation betweenSGW 134 andeNB 132. For example, different operators may simultaneously operate the same eNB in a network sharing setting. In some embodiments, communication betweeneNB 132 andUE 110 may be facilitated via theSGW 134.SGW 134 may be configured to manage signaling exchanges, e.g., authentication ofUE 110, or perform other actions associated with establishment of a communication link betweenUE 110 andPGW 140. In some embodiments,SGW 134 may be responsible for tracking and paging user equipment, e.g., whenUE 110 is in an idle mode. - The
PGW 140 may provide a gateway forUE 110 to access many other packet data networks (e.g., Internet) from, e.g.,UE 110's mobile packet core network, such ascellular network 130. In various embodiments, per flow mobility in a multi-access PDN connection may be triggered byUE 110 orPGW 140, using a bidirectional signaling protocol, such as the IFCP disclosed herein. The IFCP may be terminated inUE 110 orPGW 140. IFCP messages may be transported at layer 3 over UDP/IP or TCP/IP. In some embodiments, the IFCP protocol may be used after a multi-access PDN connection has been established (e.g., over 3GPP and WLAN accesses) in order to support UE-initiated and network-initiated IP flow mobility over a multi-access PDN connection. - In various embodiments,
UE 110 may negotiate the NBIFOM capability withPGW 140 when a new PDN connection is established.UE 110 may transfer routing rules toPGW 140 and trigger UE-initiated IP flow mobility.UE 110 may accept or reject IP flow mobility request initiated byPGW 140.UE 110 may notifyPGW 140 whenUE 110 is out of WLAN coverage and in turn suspend some flows. By the same token,UE 110 may notifyPGW 140 whenUE 110 is back in coverage and resume flows. - In various embodiments,
PGW 140 may similarly negotiate the NBIFOM capability when a new PDN connection is established, trigger network-initiated IP flow mobility, and transfer routing rules toUE 110. Further,PGW 140 may also accept or reject UE-initiated IP flow mobility. - In various embodiments, the underlying layer-2 links of a multi-access PDN connection between
UE 110 andPGW 140 may be logically combined so that these layer-2 links may appear as a single interface to the IP protocol stack. In various embodiments,PGW 140 may support the multi-access PDN connection to the same APN, such asAPN 150. - In various embodiments,
APN 150 may identify the target PDN thatUE 110 may target for communication. In addition to identifying the target PDN,APN 150 may define the type of service provided by the PDN, e.g. connection to Wireless Application Protocol (WAP) server and/or Multimedia Messaging Service (MMS). In various embodiments,APN 150 may include a gateway between a GPRS, 3G, or 4G mobile network and another computer network. As an example,APN 150 may be a Voice over LTE (VoLTE) APN. As another example,APN 150 may be a IP Multimedia Subsystem (IMS) Services APN. As yet another example,APN 150 may be a type of Voice over Data (VoD) Services APN. As yet another example,APN 150 may be an Internet APN. - For ease of illustration, various descriptions herein are provided to conform to 3GPP in the
communication system 100; however, the subject matter of the present disclosure is not limited in this regard, and the embodiments disclosed herein may be advantageously applied to other wired or wireless communication protocols or networks. -
FIG. 2 is a schematic block diagram illustrating a UE and a PGW enabled to communicate with the IFCP, in accordance with various embodiments. TheUE 210 may be similar to, and substantially interchangeable with,UE 110 ofFIG. 1 . The PGW 220 may be similar to, and substantially interchangeable with,PGW 140 ofFIG. 1 . - In various embodiments,
UE 210 may include one ormore antennas 218 andcommunication module 212. In various embodiments,communication module 212 may include signalingcircuitry 214 andprocessing circuitry 216 as shown. In various embodiments, signalingcircuitry 214 may be in a separate module. In various embodiments,processing circuitry 216 may be in a separate module. In various embodiments, signalingcircuitry 214 and processing circuitry may be in a separate module or may be both in different modules. In various embodiments, thecommunication module 212 may be coupled with theantennas 218 to facilitate over-the-air communication of signals betweenUE 210 and other wireless devices. For example, the signalingcircuitry 214 may be configured to provide various signal processing operations on the signal to theantennas 218 with suitable characteristics. In various embodiments, operations of thesignaling circuitry 214 may include, but are not limited to, filtering, amplifying, storing, modulating, demodulating, and transforming, and like operations/processes, by way of example and not limitation. - In some embodiments, the
UE 210 may include one ormore antennas 218 to concurrently utilize radio resources of multiple respective component carriers. For example, theUE 210 may be configured to communicate using orthogonal frequency division multiple access (OFDMA) (in, e.g., downlink communications) and/or single-carrier frequency-division multiple access (SC-FDMA) (in, e.g., uplink communications). In some embodiments, theUE 210 may use thesignaling circuitry 214 to communicate with another UE via LTE ProSe or LTE Direct. - The signaling
circuitry 214 may be configured to receive signals from theantennas 218, and then transmit the signals to other components of theUE 210, for example, theprocessing circuitry 216 for internal processing. In various embodiments, theprocessing circuitry 216 may enable IP flow mobility betweenUE 210 and PGW 220 based at least in part on an IFCP that enables a coexistence of UE-initiated IP flow mobility and PDN-GW-initiated IP flow mobility with a multi-access packet data network (PDN) connection. - In some embodiments, the
processing circuitry 216 of theUE 210 may send an IFCP capability request, regarding the type of network based IP flow mobility (NBIFOM) capability supported by the PGW, to the PGW 220, and the PGW 220 may send a response to theUE 210 where the response provides information about the capability of the PGW 220. The processing circuitry may receive an IFCP capability request, regarding the type of NBIFOM capability supported by theUE 210, from the PGW 220, and theUE 210 may send a response to the PGW 220 where the response provides information about the capability of theUE 210. - In some embodiments, the
processing circuitry 216 may receive an IFCP mode request from the PGW to indicate a mode of operation for IP flow mobility for Network-initiated IP flow mobility. Theprocessing circuitry 216 may send an IFCP mode request to the PGW to indicate a mode of operation of IP flow mobility for UE-initiated IP flow mobility. Theprocessing circuitry 216 may receive an IFCP mode response from the PGW to indicate a mode of operation of IP flow mobility for UE-initiated IP flow mobility. Theprocessing circuitry 216 may send an IFCP mode response to the PGW to indicate a mode of operation for IP flow mobility for Network-initiated IP flow mobility. - The
processing circuitry 216 may send an IFCP suspend request to the PGW to suspend the multi-access PDN. Theprocessing circuitry 216 may send an IFCP resume request to the PGW to resume the multi-access PDN. - The
processing circuitry 216 may receive an IFCP flow mobility request to negotiate routing rules between the UE and the PGW. Theprocessing circuitry 216 may transmit an IFCP flow mobility request to negotiate routing rules between the UE and the PGW. Theprocessing circuitry 216 may receive an IFCP flow mobility response to negotiate routing rules between the UE and the PGW. Theprocessing circuitry 216 may transmit an IFCP flow mobility response to negotiate routing rules between the UE and the PGW. - The
processing circuitry 216 may prioritize Access Network Discovery and Selection Function (ANDSF) rules over RAN rules for routing traffic. Theprocessing circuitry 216 may prioritize Network-initiated routing rules over UE-initiated routing rules. - Some or all of the
signaling circuitry 214 and/orprocessing circuitry 216 may be included in, for example,application circuitry 630, radio frequency (RF)circuitry 610 orbaseband circuitry 620 as described below with respect toFIG. 6 . In various embodiments, theUE 210 may be, may include, or may be included in a single sensor device, a cellular telephone, a personal computer (PC), a notebook, an ultrabook, a netbook, a smartphone, an ultra mobile PC (UMPC), a handheld mobile device, a universal integrated circuit card (UICC), a personal digital assistant (PDA), a Customer Premise Equipment (CPE), a tablet computing device, or other consumer electronics such as MP3 players, digital cameras, and the like. In some embodiments, theUE 210 may include a mobile station, as defined by IEEE 802.16e (2005 or 802.16m (2009) or some other revision of the IEEE 802.16 standard, or user equipment, as defined by 3GPP LTE Release 8 (2008), Release 9 (2009), Release 10 (2011), Release 12 (2014), Release 13 (under development), or some other revision or release of the 3GPP LTE standards. - In various embodiments, PGW 220 may include
control module 222 andcommunication module 224, coupled with each other, to manage Internet Protocol (IP) flow mobility between theUE 210 and the PDN-GW based at least in part on a user plane bidirectional signaling protocol that enables a coexistence of a PDN-GW-initiated IP flow mobility type and a UE-initiated flow mobility type. - In some embodiments,
communication module 224 may include anS2 interface 226 and an S5/S8 interface 228 to communicate with communication networks with different radio technologies. In various embodiments, PGW 220 may include S2 control and data plane stacks to support the S2 interface 226 (e.g., including S2a or S2b interface) to communicate with, e.g.,TWAN 122 orePDG 124 ofFIG. 1 . On the other hand, PGW 220 may include S5/S8 control and data plane stacks to support S5/S8 interface 228 to communicate with, e.g.,SGW 134 ofFIG. 1 . In some embodiments, the integrated control/data plane stacks for S5/S8 interface 228 may include IP, UDP, eGTP-C, etc. - In some embodiments, IFCP messages may be transported via S2a interface (e.g., via GTP or PMIPv6) or an S2b interface (e.g., via GTP or PMIPv6) through a WLAN network between
UE 210 and PGW 220. In some embodiments, IFCP messages may be transported via an S5 interface through a cellular network betweenUE 210 and PGW 220. In various embodiments, IFCP may impactonly UE 210, PGW 220, and the Policy Control and Charging Rules Function (PCRF) (not shown), e.g., when dynamic Policy and Charging Control (PCC) is deployed. In various embodiments, in order to establish an IFCP session, the IP address of PGW 220 may be provided toUE 210 during PDN connection establishment. Further, IFCP may use IPSec or Datagram Transport Layer Security (DTLS) for security betweenUE 210 and PGW 220. -
FIG. 3 is a flowchart illustrating a process for enabling IP flow mobility between a UE and a PGW, in accordance with various embodiments. Theprocess 300 may be performed by a UE, e.g.,UE 110 ofFIG. 1 orUE 210 ofFIG. 2 . In various embodiments, theprocess 300 may enable a UE to utilize the IFCP to manage IP flow mobility. - The
process 300 may include, at 310, enabling IP flow mobility between a UE and a PGW based at least in part on an IFCP that enables a coexistence of UE-initiated IP flow mobility and Network-initiated IP flow mobility with a multi-access packet data network (PDN) connection. - In various embodiments, the IFCP may enable a co-existence mechanism between Network (PCC/PCRF Rules) and Client (ANDSF, RAN rules) initiated IP Flow Mobility triggers and policies. As an example, in various embodiments, the IFCP may enable a UE and a PGW to negotiate and exchange routing filters between the UE and the PGW. Thus, IP flow mobility may be initiated based on network policies (PCC/PCRF rules) or based on client policies such as (ANDSF or RAN rules) to support network based flow mobility. Correspondingly, triggers for IP flow mobility may be initiated in the UE and the network. The IFCP disclosed herein may provide such a mechanism for co-existence between these scenarios so that conflicts may be resolved and different deployment scenarios may be supported.
- The IFCP may be supported at the layer 3 over UDP/IP or TCP/IP. As a user plane signaling solution, the UE or PGW may notify the peer entity (e.g., PGW/UE respectively) of a change in IP flow routing preference via the IFCP. This user plane signaling solution may enable IP flow mobility by only impacting a small number of entities, for example, UE, P-GW and PCRF and without affecting other network entities (e.g., MME, S-GW, TWAG, ePDG, AAA server and corresponding protocols (GTP-C, EAP, WLCP, IKEv2 and NAS)). The IFCP may also enable WLAN to signal a switch in the routing of an IP flow from a failing cellular connection to WLAN when using S2a Spatial Channel Module (SCM), which is problematic in the existing control plane signaling approach.
- The
process 300 further may include, at 320, receiving or transmitting (sending) an IFCP capability request or response between the UE and the PGW to indicate NB-IFOM capability supported by the UE or the PGW. In some embodiments, IFCP messages of IFCP Capability Request/Response (e.g., as illustrated at Table 1 and Table 2) may be used to query a UE or a PGW for their NB-IFOM capability. In various embodiments, the UE or the PGW may check for support of Network Based IP Flow Mobility (NBIFOM) with the other peer, which responds with a Boolean NBIFOM Capability Support indicating whether NBIFOM Capability is supported or not. Therefore, the UE and the PGW may communicate their respective NBIFOM capability. -
TABLE 1 IFCP Capability Request. IEI Information Element Type/Reference Presence Format Length IFCP Capability request Message type M V message identity Procedure transaction Transaction identifier M V identity NBIFOM Capability BOOLEAN M V Support -
TABLE 2 IFCP Capability Response. IEI Information Element Type/Reference Presence Format Length IFCP Capability response Message type M V message identity Procedure transaction Transaction identifier M V identity NBIFOM Capability BOOLEAN M V Support -
FIG. 4 is a flowchart illustrating anotherprocess 400 for enabling IP flow mobility between a UE and a PDN Gateway (PGW), in accordance with various embodiments. Theprocess 400 may be performed by a UE, e.g.,UE 110 ofFIG. 1 orUE 210 ofFIG. 2 . In various embodiments, theprocess 400 may enable a UE to utilize the IFCP to manage IP flow mobility. - The
process 400 may include, at 410, receiving or transmitting (sending) an IFCP mode request or response between the UE and the PGW to indicate a mode of operation as the UE-initiated IP flow mobility or the Network-initiated IP flow mobility. In some embodiments, IFCP messages of IFCP Mode Setup Request/Response (e.g., as illustrated at Table 3 and Table 4) may be used to setup either the UE Mode or Network mode of operation. The UE may set the UE mode of operation wherein UE initiates changes in routing rules. The PGW may accept/reject the rules and vice versa for Network mode of operation initiated by the PGW. -
TABLE 3 IFCP Mode Setup Request. IEI Information Element Type/Reference Presence Format Length IFCP Mode Setup Message type M V request message identity Procedure transaction Transaction identifier M V identity NBIFOM Mode NBIFOM Mode Type M TLV (UE Initiated or Network Initiated) -
TABLE 4 IFCP Mode Setup Response. IEI Information Element Type/Reference Presence Format Length IFCP Mode Setup Message type M V response message identity Procedure transaction Transaction identifier M V identity Response Code Result Type M TLV - The
process 400 may further include, at 420, receiving or transmitting (sending) an IFCP flow mobility request or response to negotiate routing rules between the UE and the PGW. In some embodiments, IFCP messages of IFCP Flow Mobility Request/Response (e.g., as illustrated at Table 5 and Table 6) may be used by the UE or the PGW to send routing rules to the peer in a IFCP Flow Mobility request message, and the peer may respond in Response Code in IFCP Flow Mobility Response message whether the routing rules may be accepted. - In various embodiments, a routing rule may include various parameters, such as routing filter, routing access information, routing rule priority, routing rule identifier, etc. A routing filter may include IP header parameter values/ranges used to identify one or more IP flows. The routing access information may identify the access type where the IP flow shall be routed. For the purpose of matching user traffic against routing rules, the filters may be applied in the order of the routing rule priority. The routing rule identifier may uniquely identify a routing rule for one PDN Connection. The routing rule identifier may be allocated by the entity creating the routing rule, e.g., by the UE in UE-initiated NBIFOM mode and by the PGW in a Network-initiated NBIFOM mode. The routing rule information may be encapsulated in PCO datatype.
-
TABLE 5 IFCP Flow Mobility Request. IEI Information Element Type/Reference Presence Format Length IFCP Flow Mobility Message type M V request message identity Procedure transaction Transaction identifier M V identity Access point name Access point name M TLV PDN connection ID PDN connection ID M TLV 27 Protocol configuration Protocol configuration O TLV options/Routing rules options -
TABLE 6 IFCP flow Mobility Response. IEI Information Element Type/Reference Presence Format Length IFCP Flow Mobility Message type M V response message identity Procedure transaction Transaction identifier M V identity PDN connection ID PDN connection ID M TLV 27 Protocol configuration Protocol configuration O TLV options/Routing Rules options Response Code Result Type M TLV - The
process 400 may further include, at 430, transmitting (sending) an IFCP suspend/resume request to the PGW to suspend/resume the multi-access PDN. In various embodiments, the UE may transmit (send) a suspend request (e.g., as illustrated at Table 7) to the PGW to suspend specific PDN connections. Similarly, the PGW may send a suspend response (e.g., as illustrated at Table 8) to the UE to respond to the suspend request. By the same token, the UE may send a resume request (e.g., as illustrated at Table 9) to the PGW to resume specific PDN connections. Similarly, the PGW may send a resume response (e.g., as illustrated at Table 10) to the UE to respond to the resume request. -
TABLE 7 IFCP Suspend Request. IEI Information Element Type/Reference Presence Format Length IFCP Suspend request Message type M V message identity Procedure transaction Transaction identifier M V identity PDN connection ID PDN connection ID M TLV -
TABLE 8 IFCP Suspend Response. IEI Information Element Type/Reference Presence Format Length IFCP Suspend response Message type M V message identity Procedure transaction Transaction identifier M V identity PDN connection ID PDN connection ID M TLV Response Code Result Type M TLV -
TABLE 9 IFCP Resume Request. IEI Information Element Type/Reference Presence Format Length IFCP Resume request Message type M V message identity Procedure transaction Transaction identifier M V identity PDN connection ID PDN connection ID M TLV -
TABLE 10 IFCP Resume Response. IEI Information Element Type/Reference Presence Format Length IFCP Resume response Message type M V message identity Procedure transaction Transaction identifier M V identity PDN connection ID PDN connection ID M TLV Response Code Result Type M TLV -
FIG. 5 is a flowchart illustrating yet anotherprocess 500 for enabling IP flow mobility between a UE and a PDN Gateway (PGW), in accordance with various embodiments. Theprocess 500 may be performed by a PGW, e.g., thePGW 140 ofFIG. 1 or PGW 220 ofFIG. 2 . - The
process 500 may include, at 510, managing Internet Protocol (IP) flow mobility between a UE and the PGW based at least in part on a user plane bidirectional signaling protocol (e.g., the IFCP) that enables a coexistence of a Network-initiated IP flow mobility type and a UE-initiated flow mobility type. In some embodiments, the IFCP may enable a UE or a PGW to use a single procedure/message to move multiple IP flows. - In some embodiments, the IFCP may enable a UE or a PGW to negotiate, accept, or reject routing rules. In some embodiments, the IFCP may enable a UE or a PGW to transfer routing rules over any target network, including S2a SCM or a network utilizing PMIP. In some embodiments, the IFCP may reduce overhead when a PGW allows IFCP traffic on an NBIFOM PDN connection and may take this into account for its charging and usage monitoring counters. In some embodiments, the IFCP may enable a UE or a PGW to use IPSec or DTLS to counter any security impacts to prevent a malware from attacking the IFCP stack in the PGW.
- The
process 500 may further include, at 520, using the user plane bidirectional signaling protocol to negotiate a plurality of parameters of the Network-initiated IP flow mobility type or the UE-initiated flow mobility type between the UE and the PGW when the UE establishes a multi-access PDN connection to the PGW. Thus, UE-initiated NBIFOM may co-exist with Network-initiated NBIFOM. - IP Flow mobility may be initiated based on network policies (for example, PCC/PCRF rules) or based on client policies (for example, ANDSF or RAN rules) to support network-based flow mobility. Corresponding triggers for IP flow mobility may be initiated in the UE and the network. The IFCP may provide a mechanism for co-existence between these scenarios so that conflicts can be resolved and different deployment scenarios can be supported.
- 3GPP Rel-12 solution based on RAN rules specifies that APN-level offloading and mobility may be done on a per PDN Connection granularity. Hence, when RAN rules are satisfied, the UE moves the offloadable PDN connections from 3GPP to WLAN. The MME/SGSN indicates, via NAS signaling, the PDN Connections that are offloadable to WLAN. The RAN may be oblivious regarding which mobility solution is used and whether PDN level mobility or flow level mobility is used. With NBIFOM, it is not clear how RAN rules that govern PDN level mobility may affect flow level mobility. Thus, the IFCP provides a co-existence mechanism in conjunction with PCC/PCRF rules for NBIFOM.
- The granularity for deciding what traffic may be offloaded to WLAN may be set on IP Flow level. The per RAT WLAN offloadability indication per PDN Connection may be used for NBIFOM PDN connections as well.
- ANDSF rules may have preference (or priority) over RAN rules. If no ANDSF rule is present, then RAN rules may be used. ANDSF rules may always be used in roaming scenarios. In some embodiments, traffic may be routed to WLAN only if both client and network rules to move traffic to WLAN are satisfied. Otherwise, traffic may be routed on 3GPP access only, such as illustrated in the routing rule negotiation items of Table 11.
- In various embodiments, a choice may be made between only allowing the UE to initiate IP flow mobility (UE-controlled mode) or only allowing the network to initiate IP flow mobility (NW-controlled mode). If the UE is provisioned with IFOM routing rules (for example, ANDSF rules) or RAN Rules, the UE may request UE-controlled mode during IFCP session setup. If the UE does not request UE-controlled mode, the network may inform the UE that NW-controlled mode will be used. The UE can use the ANDSF routing rules or RAN rules when the UE-controlled mode is negotiated. When the NW-controlled mode is negotiated, the UE does not use any ANDSF routing rules or RAN rules (it uses the network-provided rules instead).
-
TABLE 11 Routing Rule Negotiation. ANDSF Rule Network Rule IP Flow Item Status RAN Rule status Status route 1 WLAN 3GPP 3GPP 3GPP 2 WLAN WLAN 3GPP 3GPP 3 3GPP 3GPP 3GPP 3GPP 4 3GPP WLAN 3GPP 3GPP 5 WLAN 3GPP WLAN WLAN 6 WLAN WLAN WLAN WLAN 7 3GPP 3GPP WLAN 3GPP 8 3GPP WLAN WLAN 3GPP 9 None WLAN WLAN WLAN - A UE may request UE Mode of operation, and the network may accept that request. If no network rules apply, then the UE mode of operation may be selected. In some embodiments, network may have PCC or PCRF rules. Network may request NW mode of operation, and UE may accept that. If no UE rules are provided, then a Network mode of operation may be selected. In some embodiments, if both a UE and a Network have rules, the Network may gain precedence over the UE, and NW mode of operation may be selected. In some embodiments, the selected rules may be applied based on the agreed mode of operation, and the IP Flow routing may be selected accordingly.
- In some embodiments, IP flow routing may include one or more options. When a UE has AND SF rules and RAN rules, the ANDSF rules may take priority of the RAN rules. When a UE has either ANDSF rules and RAN rules, the UE may request a UE mode of operation for IP flow routing to the network. If the network does not have IP flow routing rules, the network may accept the UE request and confirm that IP flow routing is to be performed using the UE mode of operation for IP flow routing. If the network does have IP flow routing rules, the network may reject the UE request and may make a network request to the UE to use the network rules for IP flow routing, and the UE may accept that request. If the UE does not have IP flow routing rules, the network may make a request for IP flow routing based on network rules. The UE may accept the request and use the network rules. If both the UE and the network have IP flow routing rules, the network rules may take priority over the UE rules.
-
UE 110 andPGW 140 ofFIG. 1 orUE 210 and PGW 220 ofFIG. 2 may be implemented into a system using any suitable hardware, firmware, and/or software configured as desired.FIG. 6 illustrates, for an embodiment, anexample system 600 comprising radio frequency (RF)circuitry 610,baseband circuitry 620,application circuitry 630, memory/storage 640,display 650,camera 660,sensor 670, and input/output (I/O)interface 680, coupled with each other at least as shown, which may be used to implementUE 110,PGW 140 ofFIG. 1 orUE 210, PGW 220 ofFIG. 2 . - The
application circuitry 630 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with memory/storage 640 and configured to execute instructions stored in the memory/storage 640 to enable various applications and/or operating systems running on thesystem 600. - The
baseband circuitry 620 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include a baseband processor. Thebaseband circuitry 620 may handle various radio control functions that enable communication with one or more radio networks via theRF circuitry 610. The radio control functions may include, but are not limited to, signal modulation, encoding, decoding, radio frequency shifting, etc. In some embodiments, thebaseband circuitry 620 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, thebaseband circuitry 620 may support communication with an EUTRAN and/or other WMAN, a WLAN, or a WPAN. Embodiments in which thebaseband circuitry 620 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry. - In various embodiments,
baseband circuitry 620 may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some embodiments,baseband circuitry 620 may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency. - In some embodiments, the
processing circuitry FIG. 2 may be embodied in theapplication circuitry 630 and/or thebaseband circuitry 620. -
RF circuitry 610 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, theRF circuitry 610 may include switches, filters, amplifiers, etc., to facilitate the communication with the wireless network. - In various embodiments,
RF circuitry 610 may include circuitry to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments,RF circuitry 610 may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency. - In some embodiments, the signaling
circuitry FIG. 2 may be embodied in theRF circuitry 610. - In some embodiments, some or all of the constituent components of the
baseband circuitry 620, theapplication circuitry 630, and/or the memory/storage 640 may be implemented together on a system on a chip (SOC). - Memory/
storage 640 may be used to load and store data and/or instructions, for example, forsystem 600. Memory/storage 640 for one embodiment may include any combination of suitable volatile memory (e.g., dynamic random access memory (DRAM)) and/or non-volatile memory (e.g., flash memory). - In various embodiments, the I/
O interface 680 may include one or more user interfaces to enable user interaction with thesystem 600 and/or peripheral component interfaces to enable peripheral component interaction with thesystem 600. User interfaces may include, but are not limited to, a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface. - In various embodiments,
sensor 670 may include one or more sensing devices to determine environmental conditions and/or location information related to thesystem 600. In some embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, thebaseband circuitry 620 and/orRF circuitry 610 to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite. - In various embodiments, the
display 650 may include a display, e.g., a liquid crystal display, a touch screen display, etc. In some embodiments, thecamera 660 may include many molded plastic aspheric lens elements made with varying dispersion and refractive indexes. In some embodiments, thecamera 660 may include two or more lenses to capture three-dimensional images for stereo photography. - In various embodiments, the
system 600 may be a mobile computing device such as, but not limited to, a smartphone, a tablet computing device, a netbook, an ultrabook, a laptop computing device, etc. In various embodiments,system 600 may have more or fewer components, and/or different architectures. -
FIG. 7 illustrates an article ofmanufacture 710 having programming instructions, incorporating aspects of the present disclosure, in accordance with various embodiments. In various embodiments, an article of manufacture may be employed to implement various embodiments of the present disclosure. As shown, the article ofmanufacture 710 may include a computer-readablenon-transitory storage medium 720 where instructions 730 are configured to practice embodiments of or aspects of embodiments of any one of the processes described herein. Thestorage medium 720 may represent a broad range of persistent storage media known in the art, including but not limited to flash memory, dynamic random access memory, static random access memory, an optical disk, a magnetic disk, etc. In embodiments, computer-readable storage medium 720 may include one or more computer-readable non-transitory storage media. In other embodiments, computer-readable storage medium 720 may be transitory, such as signals, encoded with instructions 730. - In various embodiments, instructions 730 may enable an apparatus, in response to its execution by the apparatus, to perform various operations described herein. As an example,
storage medium 720 may include instructions 730 configured to cause an apparatus, e.g.,UE 110 ofFIG. 1 orUE 210 ofFIG. 2 , to practice some aspects of IP flow mobility control, e.g., as illustrated inprocess 300 ofFIG. 3 orprocess 400 ofFIG. 4 , in accordance with embodiments of the present disclosure. As another example,storage medium 720 may include instructions 730 configured to cause an apparatus, e.g.,PGW 140 ofFIG. 1 or PGW 220 ofFIG. 2 , to practice some aspects of IP flow mobility control, e.g., as illustrated inprocess 500 ofFIG. 5 , in accordance with embodiments of the present disclosure. - The following paragraphs describe examples of various embodiments disclosed herein.
- A first kind of examples may include an apparatus, such as a user equipment (UE), which may include signaling circuitry to establish a multi-access packet data network (PDN) connection with at least two radio access technologies to enable Internet Protocol (IP) flow mobility based on the at least two radio access technologies; and processing circuitry, coupled to the signaling circuitry, to control IP flow mobility between the UE and a PDN Gateway (PGW) based on a bidirectional signaling protocol that enables a coexistence of IP flow mobility initiated based on network policies and IP flow mobility initiated based on UE policies.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the bidirectional signaling protocol is terminated at the UE and the PGW, and the processing circuitry is to negotiate routing rules between the UE and the PGW using the bidirectional signaling protocol over Transmission Control Protocol (TCP)/IP or User Datagram Protocol (UDP)/IP.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the signaling circuitry is to exchange routing rules between the UE and the PGW based on the negotiation.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the processing circuitry is to use the bidirectional signaling protocol to negotiate Network-based IP flow mobility (NB-IFOM) capability between the UE and the PGW when the multi-access PDN connection is established.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the processing circuitry is to use the bidirectional signaling protocol to trigger UE-initiated IP flow mobility and negotiate routing rules based on the network policies and the UE policies.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the processing circuitry is to use the bidirectional signaling protocol to accept or reject network-initiated IP flow mobility and negotiate routing rules based on the network policies and the UE policies.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the at least two radio access technologies comprises a WiFi technology to access a wireless local area network (WLAN), wherein the processing circuitry is to notify the PGW using the bidirectional signaling protocol when the UE is out of the WLAN, and request the PGW to stop sending downlink packages over the WLAN to the UE.
- Another example may include the apparatus of any of the preceding first kind of examples, wherein the processing circuitry is to notify the PGW using the bidirectional signaling protocol when the UE is back in the WLAN, and request the PGW to resume sending downlink packages over the WLAN to the UE.
- A second kind of examples may include a method, comprising: enabling IP flow mobility between a UE and a PDN Gateway (PGW) based at least in part on an IP Flow mobility Control Protocol (IFCP) that enables a coexistence of UE-initiated IP flow mobility and Network-initiated IP flow mobility with a multi-access packet data network (PDN) connection; and receiving or sending an IFCP capability request or response between the UE and the PGW to indicate a type of IP flow mobility (NB-IFOM) capability supported by the UE or the PGW.
- Another example may include the method of any of the preceding second kind of examples, and the method further include receiving or sending an IFCP mode request or response between the UE and the PGW to indicate a mode of operation as the UE-initiated IP flow mobility or the Network-initiated IP flow mobility.
- Another example may include the method of any of the preceding second kind of examples, and the method further include sending an IFCP suspend request to the PGW to suspend the multi-access PDN; and sending an IFCP resume request to the PGW to resume the multi-access PDN.
- Another example may include the method of any of the preceding second kind of examples, and the method further include receiving or sending an IFCP flow mobility request or response to negotiate routing rules between the UE and the PGW.
- Another example may include the method of any of the preceding second kind of examples, and the method further include prioritizing Access Network Discovery and Selection Function (ANDSF) rules over Radio Access Network (RAN) rules for routing traffic; or prioritizing Network-initiated routing rules over UE-initiated routing rules.
- Another example may include an apparatus comprising means to perform any of the preceding second kind of examples.
- Another example may include one or more non-transitory computer readable media comprising instructions to cause an apparatus, upon execution of the instructions by one or more processors of the apparatus, to perform any of the preceding second kind of examples.
- A third kind of examples may include an apparatus, such as a packet data network gateway (PGW), which may include a communication module to communicate with a UE via a multi-access packet data network (PDN) connection; and a control module to manage Internet Protocol (IP) flow mobility between the UE and the PGW based at least in part on a user plane bidirectional signaling protocol that enables a coexistence of a Network-initiated IP flow mobility type the and a UE-initiated flow mobility type.
- Another example may include the apparatus of any of the preceding third kind of examples, wherein the control module is to use the user plane bidirectional signaling protocol to negotiate a plurality of capability parameters of the Network-initiated IP flow mobility type or the UE-initiated flow mobility type between the UE and the PGW when the UE establishes the multi-access PDN connection to the PGW.
- Another example may include the apparatus of any of the preceding third kind of examples, wherein the control module is to use the user plane bidirectional signaling protocol to accept or reject a UE-initiated IP flow mobility session.
- Another example may include the apparatus of any of the preceding third kind of examples, wherein the control module is to use the user plane bidirectional signaling protocol to trigger a Network-initiated IP flow mobility session and transfer routing rules based on network policies to the UE.
- A forth kind of examples may include a method, comprising: managing Internet Protocol (IP) flow mobility between a UE and the PGW based at least in part on a user plane bidirectional signaling protocol that enables a coexistence of a Network-initiated IP flow mobility type and a UE-initiated flow mobility type; and using the user plane bidirectional signaling protocol to negotiate a plurality of capability parameters of the Network-initiated IP flow mobility type or the UE-initiated flow mobility type between the UE and the PGW when the UE establishes a multi-access PDN connection to the PGW
- Another example may include the method of any of the preceding forth kind of examples, and the method further include using the user plane bidirectional signaling protocol to trigger a Network-initiated IP flow mobility session based on Policy and Charging Control (PCC) or Policy and Charging Rule Function (PCRF).
- Another example may include the method of any of the preceding forth kind of examples, and the method further include using the user plane bidirectional signaling protocol to accept or reject a UE-initiated IP flow mobility session.
- Another example may include the method of any of the preceding forth kind of examples, and the method further include routing traffic via a WLAN only if the PGW and the UE agree on a WLAN based routing rule based on the user plane bidirectional signaling protocol.
- Another example may include the method of any of the preceding forth kind of examples, and the method further include prioritizing Network-initiated routing rules over UE-initiated routing rules.
- Another example may include the method of any of the preceding forth kind of examples, and the method further include transferring Network-initiated routing rules to the UE using the user plane bidirectional signaling protocol.
- Another example may include the method of any of the preceding forth kind of examples, and the method further include receiving an IFCP flow mobility request or send an IFCP flow mobility response to negotiate routing rules between the PGW and the UE.
- Another example may include an apparatus comprising means to perform any of the preceding forth kind of examples.
- Another example may include one or more non-transitory computer readable media comprising instructions to cause an apparatus, upon execution of the instructions by one or more processors of the apparatus, to perform any of the preceding forth kind of examples.
- The description herein of illustrated implementations, including what is described in the Abstract, is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. While specific implementations and examples are described herein for illustrative purposes, a variety of alternate and/or equivalent embodiments or implementations calculated to achieve the same purposes may be made in light of the above detailed description, without departing from the scope of the present disclosure, as those skilled in the relevant art will recognize.
Claims (23)
1. An apparatus to be implemented in a user equipment (UE), the apparatus comprising:
signaling circuitry to establish a multi-access packet data network (PDN) connection with at least two radio access technologies to enable Internet Protocol (IP) flow mobility based on the at least two radio access technologies; and
processing circuitry, coupled to the signaling circuitry, to control IP flow mobility based on a bidirectional signaling protocol between the UE and a PDN Gateway (PGW) that enables a coexistence of IP flow mobility initiated based on network policies and IP flow mobility initiated based on UE policies.
2. The apparatus of claim 1 , wherein the bidirectional signaling protocol is terminated at the UE and the PGW, and the processing circuitry is to negotiate routing rules between the UE and the PGW using the bidirectional signaling protocol over Transmission Control Protocol (TCP)/IP or User Datagram Protocol (UDP)/IP.
3. The apparatus of claim 2 , wherein the signaling circuitry is to exchange routing rules between the UE and the PGW based on the negotiation.
4. The apparatus of claim 1 , wherein the processing circuitry is to use the bidirectional signaling protocol to negotiate Network-based IP flow mobility (NB-IFOM) capability between the UE and the PGW when the multi-access PDN connection is established.
5. The apparatus of claim 1 , wherein the processing circuitry is to use the bidirectional signaling protocol to trigger UE-initiated IP flow mobility and negotiate routing rules based on the network policies and the UE policies.
6. The apparatus of claim 1 , wherein the processing circuitry is to use the bidirectional signaling protocol to accept or reject network-initiated IP flow mobility and negotiate routing rules based on the network policies and the UE policies.
7. The apparatus of claim 1 , wherein the at least two radio access technologies comprises a WiFi technology to access a wireless local area network (WLAN), wherein the processing circuitry is to notify the PGW using the bidirectional signaling protocol when the UE is out of the WLAN, and request the PGW to stop sending downlink packages over the WLAN to the UE.
8. The apparatus of claim 7 , wherein the processing circuitry is to notify the PGW using the bidirectional signaling protocol when the UE is back in the WLAN coverage, and request the PGW to resume sending downlink packs over the WLAN to the UE.
9. One or more non-transitory computer readable media comprising instructions to cause a user equipment (UE), in response to execution of the instructions by a processor of the UE, to:
enable IP flow mobility between a UE and a PDN Gateway (PGW) based at least in part on an IP Flow mobility Control Protocol (IFCP) that enables a coexistence of UE-initiated IP flow mobility and network-initiated IP flow mobility with a multi-access packet data network (PDN) connection; and
receive or send an IFCP capability request or response between the UE and the PGW to indicate a type of IP flow mobility (NB-IFOM) capability supported by the UE or the network.
10. The one or more non-transitory computer-readable media of claim 9 , wherein the instructions, when executed, further cause the UE to:
receive or send an IFCP mode request or response between the UE and the PGW to indicate a mode of operation as the UE-initiated IP flow mobility or the Network-initiated IP flow mobility.
11. The one or more non-transitory computer-readable media of claim 9 , wherein the instructions, when executed, further cause the UE to:
send an IFCP suspend request to the PGW to suspend the multi-access PDN; and
send an IFCP resume request to the PGW to resume the multi-access PDN.
12. The one or more non-transitory computer-readable media of claim 9 , wherein the instructions, when executed, further cause the UE to:
receive or send an IFCP flow mobility request or response to negotiate routing rules between the UE and the PGW.
13. The one or more non-transitory computer-readable media of claim 9 , wherein the instructions, when executed, further cause the UE to:
prioritize Access Network Discovery and Selection Function (ANDSF) rules over Radio Access Network (RAN) rules for routing traffic; and
prioritize network-initiated routing rules (PCC rules or PCRF rules) over UE-initiated routing rules, wherein the network-initiated rules comprise at least one Policy and Charging Control (PCC) rules or Policy and Charging Rule Function (PCRF) rules.
14. A packet data network gateway (PGW), comprising:
a communication module to communicate with a UE via a multi-access packet data network (PDN) connection; and
a control module to manage Internet Protocol (IP) flow mobility between the UE and the PGW based at least in part on a user plane bidirectional signaling protocol that enables a coexistence of a Network-initiated IP flow mobility type the and a UE-initiated flow mobility type.
15. The PGW of claim 14 , wherein the control module is to use the user plane bidirectional signaling protocol to negotiate a plurality of capability parameters of the Network-initiated IP flow mobility type or the UE-initiated flow mobility type between the UE and the PGW when the UE establishes the multi-access PDN connection to the PGW.
16. The PGW of claim 14 , wherein the control module is to use the user plane bidirectional signaling protocol to accept or reject a UE-initiated IP flow mobility session.
17. The PGW of claim 14 , wherein the control module is to use the user plane bidirectional signaling protocol to trigger a network-initiated IP flow mobility session and transfer routing rules based on network policies to the UE.
18. One or more non-transitory computer readable media comprising instructions to cause a packet data network gateway (PGW), in response to execution of the instructions by a processor of the PGW, to:
manage Internet Protocol (IP) flow mobility between a UE and the PGW based at least in part on a user plane bidirectional signaling protocol that enables a coexistence of a Network-initiated IP flow mobility type and a UE-initiated flow mobility type; and
use the user plane bidirectional signaling protocol to negotiate a plurality of capability parameters of the Network-initiated IP flow mobility type or the UE-initiated flow mobility type between the UE and the PGW when the UE establishes a multi-access PDN connection to the PGW.
19. The one or more non-transitory computer-readable media of claim 18 , wherein the instructions, when executed, further cause the PGW to:
use the user plane bidirectional signaling protocol to trigger a network-initiated IP flow mobility session based on Policy and Charging Control (PCC) or Policy and Charging Rule Function (PCRF).
20. The one or more non-transitory computer-readable media of claim 18 , wherein the instructions, when executed, further cause the PGW to:
use the user plane bidirectional signaling protocol to accept or reject a UE-initiated IP flow mobility session.
21. The one or more non-transitory computer-readable media of claim 18 , wherein the instructions, when executed, further cause the PGW to:
route traffic via a WLAN only if the network and the UE agree on a WLAN based routing rule based on the user plane bidirectional signaling protocol.
22. The one or more non-transitory computer-readable media of claim 18 , wherein the instructions, when executed, further cause the PGW to:
prioritize Network-initiated routing rules over UE-initiated routing rules; and
transfer Network-initiated routing rules to the UE using the user plane bidirectional signaling protocol.
23. The one or more non-transitory computer-readable media of claim 18 , wherein the instructions, when executed, further cause the PGW to:
receive an IFCP flow mobility request or send an IFCP flow mobility response to negotiate routing rules between the PGW and the UE.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/538,175 US20180014346A1 (en) | 2015-01-20 | 2015-06-26 | Apparatus and method for bidirectional ip flow mobility control |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562105456P | 2015-01-20 | 2015-01-20 | |
US15/538,175 US20180014346A1 (en) | 2015-01-20 | 2015-06-26 | Apparatus and method for bidirectional ip flow mobility control |
PCT/US2015/038083 WO2016118187A1 (en) | 2015-01-20 | 2015-06-26 | Apparatus and method for bidirectional ip flow mobility control |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2015/038083 A-371-Of-International WO2016118187A1 (en) | 2015-01-20 | 2015-06-26 | Apparatus and method for bidirectional ip flow mobility control |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/447,855 Continuation US11140736B2 (en) | 2015-01-20 | 2019-06-20 | Apparatus and method for bidirectional IP flow mobility control |
Publications (1)
Publication Number | Publication Date |
---|---|
US20180014346A1 true US20180014346A1 (en) | 2018-01-11 |
Family
ID=53611010
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/538,175 Abandoned US20180014346A1 (en) | 2015-01-20 | 2015-06-26 | Apparatus and method for bidirectional ip flow mobility control |
US16/447,855 Active 2035-07-24 US11140736B2 (en) | 2015-01-20 | 2019-06-20 | Apparatus and method for bidirectional IP flow mobility control |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/447,855 Active 2035-07-24 US11140736B2 (en) | 2015-01-20 | 2019-06-20 | Apparatus and method for bidirectional IP flow mobility control |
Country Status (7)
Country | Link |
---|---|
US (2) | US20180014346A1 (en) |
EP (1) | EP3248436B1 (en) |
JP (1) | JP2018506871A (en) |
KR (1) | KR102372592B1 (en) |
CN (1) | CN107113899B (en) |
BR (1) | BR112017012165A2 (en) |
WO (1) | WO2016118187A1 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170180259A1 (en) * | 2014-09-05 | 2017-06-22 | Huawei Technologies Co., Ltd. | Offloading policy negotiation method and apparatus |
US20180034726A1 (en) * | 2016-07-26 | 2018-02-01 | Alcatel-Lucent Usa Inc. | Systems and methods for multi-path communication over multiple radio access technologies |
US20180070288A1 (en) * | 2015-04-01 | 2018-03-08 | Lg Electronics Inc. | Method and user equipment for performing network selection and traffic routing |
US20190166041A1 (en) * | 2016-07-08 | 2019-05-30 | Alcatel Lucent | Flow aggregation and routing for multi-connectivity client devices |
US10516783B2 (en) * | 2015-11-19 | 2019-12-24 | Zte Corporation | Method and device for processing PCC rule |
US10701754B2 (en) * | 2015-04-07 | 2020-06-30 | Sharp Kabushiki Kaisha | Terminal devices, PGW, and TWAG |
US20210176166A1 (en) * | 2015-07-31 | 2021-06-10 | Convida Wireless, Llc | Mtc service selection in the (s)gi-lan |
US11246057B2 (en) * | 2016-05-25 | 2022-02-08 | Samsung Electronics Co., Ltd. | Method and device for transmitting signal by using multiple links |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020092933A1 (en) * | 2018-11-02 | 2020-05-07 | Intel Corporation | Techniques in retrieving cached content using information centric networking for protocol data unit sessions |
US11265242B2 (en) | 2020-01-15 | 2022-03-01 | Cisco Technology, Inc. | Systems and methods for applying SD-WAN policies to router-generated traffic |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120069817A1 (en) * | 2010-09-20 | 2012-03-22 | Xinhua Ling | Methods and apparatus to provide packet switched service continuity during circuit switched fallback operation |
US20150195863A1 (en) * | 2012-07-27 | 2015-07-09 | Interdigital Holdings, Inc. | Ip-layer device-to-device communication in mobile networks |
US20150382393A1 (en) * | 2014-06-30 | 2015-12-31 | Apple Inc. | Methods and apparatus to support network-based ip flow mobility via multiple wireless accesses for a wireless device |
US20160295465A1 (en) * | 2014-11-10 | 2016-10-06 | Telefonaktiebolaget L M Ericsson (Publ) | A Node and Method For Managing a Data Flow Between Networks of Different Access Types |
US20170201453A1 (en) * | 2014-04-08 | 2017-07-13 | China Academy of Telecommunitions Technology | Method and device for determining ip flow routing rule |
US20170238223A1 (en) * | 2014-07-24 | 2017-08-17 | Zte Corporation | Method and Device for Implementing Flow Mobility Triggering, and Storage Medium |
US20170339614A1 (en) * | 2015-01-14 | 2017-11-23 | Lg Electronics Inc. | Method for determining whether to offload traffic to wlan |
US20190001452A1 (en) * | 2017-07-03 | 2019-01-03 | Makita Corporation | Power tool |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010069601A1 (en) * | 2008-12-19 | 2010-06-24 | Nec Europe Ltd. | A radio network and a method for operating a radio network |
WO2012088716A1 (en) * | 2010-12-31 | 2012-07-05 | 华为技术有限公司 | Internet protocol (ip) stream motion method, policy and charging rules function (pcrf) and access network discovery and selection function (andsf) |
JP5786089B2 (en) * | 2011-04-07 | 2015-09-30 | インターデイジタル パテント ホールディングス インコーポレイテッド | Method and apparatus for local data caching |
CN102918922B (en) * | 2011-05-31 | 2016-12-07 | 华为技术有限公司 | Data transmission method, separation point device, subscriber equipment and system |
US8942099B2 (en) * | 2011-09-21 | 2015-01-27 | Mediatek Inc. | Method and apparatus of IP flow mobility in 4G wireless communication networks |
EP3361762A1 (en) * | 2011-11-29 | 2018-08-15 | Interdigital Patent Holdings, Inc. | Methods for ip mobility management |
MX2017000004A (en) * | 2014-06-30 | 2017-08-14 | Interdigital Patent Holdings Inc | Network-based flow mobility for multi connectivity devices. |
US20170310584A1 (en) | 2014-10-06 | 2017-10-26 | Lg Electronics Inc. | Routing rule updating method and user device for moving specific ip flow to specific access |
-
2015
- 2015-06-26 US US15/538,175 patent/US20180014346A1/en not_active Abandoned
- 2015-06-26 JP JP2017528942A patent/JP2018506871A/en active Pending
- 2015-06-26 EP EP15738201.1A patent/EP3248436B1/en active Active
- 2015-06-26 BR BR112017012165A patent/BR112017012165A2/en not_active Application Discontinuation
- 2015-06-26 CN CN201580069731.4A patent/CN107113899B/en active Active
- 2015-06-26 WO PCT/US2015/038083 patent/WO2016118187A1/en active Application Filing
- 2015-06-26 KR KR1020177016836A patent/KR102372592B1/en active IP Right Grant
-
2019
- 2019-06-20 US US16/447,855 patent/US11140736B2/en active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120069817A1 (en) * | 2010-09-20 | 2012-03-22 | Xinhua Ling | Methods and apparatus to provide packet switched service continuity during circuit switched fallback operation |
US20150195863A1 (en) * | 2012-07-27 | 2015-07-09 | Interdigital Holdings, Inc. | Ip-layer device-to-device communication in mobile networks |
US20170201453A1 (en) * | 2014-04-08 | 2017-07-13 | China Academy of Telecommunitions Technology | Method and device for determining ip flow routing rule |
US20150382393A1 (en) * | 2014-06-30 | 2015-12-31 | Apple Inc. | Methods and apparatus to support network-based ip flow mobility via multiple wireless accesses for a wireless device |
US20170238223A1 (en) * | 2014-07-24 | 2017-08-17 | Zte Corporation | Method and Device for Implementing Flow Mobility Triggering, and Storage Medium |
US20160295465A1 (en) * | 2014-11-10 | 2016-10-06 | Telefonaktiebolaget L M Ericsson (Publ) | A Node and Method For Managing a Data Flow Between Networks of Different Access Types |
US20170339614A1 (en) * | 2015-01-14 | 2017-11-23 | Lg Electronics Inc. | Method for determining whether to offload traffic to wlan |
US20190001452A1 (en) * | 2017-07-03 | 2019-01-03 | Makita Corporation | Power tool |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170180259A1 (en) * | 2014-09-05 | 2017-06-22 | Huawei Technologies Co., Ltd. | Offloading policy negotiation method and apparatus |
US11178057B2 (en) * | 2014-09-05 | 2021-11-16 | Huawei Technologies Co., Ltd. | Offloading policy negotiation method and apparatus |
US10455471B2 (en) * | 2015-04-01 | 2019-10-22 | Lg Electronics Inc. | Method and user equipment for performing network selection and traffic routing |
US20180103405A1 (en) * | 2015-04-01 | 2018-04-12 | Lg Electronics Inc. | Method and user equipment for performing network selection and traffic routing |
US10206155B2 (en) * | 2015-04-01 | 2019-02-12 | Lg Electronics Inc. | Method and user equipment for performing network selection and traffic routing |
US20180070288A1 (en) * | 2015-04-01 | 2018-03-08 | Lg Electronics Inc. | Method and user equipment for performing network selection and traffic routing |
US10701754B2 (en) * | 2015-04-07 | 2020-06-30 | Sharp Kabushiki Kaisha | Terminal devices, PGW, and TWAG |
US20210176166A1 (en) * | 2015-07-31 | 2021-06-10 | Convida Wireless, Llc | Mtc service selection in the (s)gi-lan |
US10516783B2 (en) * | 2015-11-19 | 2019-12-24 | Zte Corporation | Method and device for processing PCC rule |
US11246057B2 (en) * | 2016-05-25 | 2022-02-08 | Samsung Electronics Co., Ltd. | Method and device for transmitting signal by using multiple links |
US20190166041A1 (en) * | 2016-07-08 | 2019-05-30 | Alcatel Lucent | Flow aggregation and routing for multi-connectivity client devices |
US10873526B2 (en) * | 2016-07-08 | 2020-12-22 | Alcatel Lucent | Flow aggregation and routing for multi-connectivity client devices |
US10742541B2 (en) * | 2016-07-26 | 2020-08-11 | Nokia Of America Corporation | Systems and methods for multi-path communication over multiple radio access technologies |
US20180034726A1 (en) * | 2016-07-26 | 2018-02-01 | Alcatel-Lucent Usa Inc. | Systems and methods for multi-path communication over multiple radio access technologies |
Also Published As
Publication number | Publication date |
---|---|
EP3248436B1 (en) | 2021-02-24 |
EP3248436A1 (en) | 2017-11-29 |
JP2018506871A (en) | 2018-03-08 |
CN107113899A (en) | 2017-08-29 |
KR102372592B1 (en) | 2022-03-08 |
US11140736B2 (en) | 2021-10-05 |
CN107113899B (en) | 2021-07-30 |
BR112017012165A2 (en) | 2018-01-02 |
KR20170106955A (en) | 2017-09-22 |
US20190373662A1 (en) | 2019-12-05 |
WO2016118187A1 (en) | 2016-07-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11140736B2 (en) | Apparatus and method for bidirectional IP flow mobility control | |
US11438949B2 (en) | Methods and apparatus to support network-based IP flow mobility via multiple wireless accesses for a wireless device | |
US20210168583A1 (en) | Terminal device, mme, communication control method for terminal device, and communication control method for mme | |
KR102474135B1 (en) | Discovery and communication using a ue-to-ue relay | |
US11146956B2 (en) | Serving gateway extensions for inter-system mobility | |
US9386617B2 (en) | Discovery and operation of hybrid wireless wide area and wireless local area networks | |
US20180376446A1 (en) | De-registration method in wireless communication system and apparatus therefor | |
JP6037417B2 (en) | System and method for SAMOG bearer management | |
US10567995B2 (en) | Terminal apparatus, MME, communication method of terminal apparatus, and communication method of MME | |
EP3334239A1 (en) | Terminal device, base station device, method for controlling communication of terminal device, and method for controlling communication of base station device | |
US10887806B2 (en) | System and method for supporting 5G user devices in a legacy wireless core network | |
US10110478B2 (en) | Method and device for determining IP flow routing rule | |
CN107251611B (en) | Service processing method, related device and system | |
JP2016502315A (en) | System and method for SAMOG bearer management | |
TW201739310A (en) | Systems, methods and devices for indicating support of more than one data radio bearer for cellular internet of things devices | |
EP4027691A1 (en) | Service flow transmission control method, device, and system | |
US20190191035A1 (en) | Methods and nodes for enabling management of traffic steering policy | |
US20190174386A1 (en) | Handover procedure | |
EP4035437B1 (en) | Method and apparatus for access or rat restriction | |
US20230147272A1 (en) | Method and Apparatus for Indirect Data Forwarding |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTEL IP CORPORATION;REEL/FRAME:057338/0362 Effective date: 20210512 |