WO2017123938A1

WO2017123938A1 - Integration of non-3gpp access in a 5g system user plane framework

Info

Publication number: WO2017123938A1
Application number: PCT/US2017/013424
Authority: WO
Inventors: Mahmoud Watfa; Saad Ahmad
Original assignee: IDAC Holdings Inc
Current assignee: IDAC Holdings Inc
Priority date: 2016-01-15
Filing date: 2017-01-13
Publication date: 2017-07-20
Anticipated expiration: 2018-07-15

Abstract

A control plane (CP) node is described for offloading a data flow associated with a user equipment (UE) to an IEEE 802.11 wireless local area network (WLAN). The CP node includes an offload processor that is configured to determine to initiate offload of the data flow associated with the UE to the WLAN. The CP node includes at least one interface configured to transmit a non-access stratum (NAS) message to the UE to commence offload of the data flow associated with the UE to the WLAN. The at least one interface is further configured to update a context associated with the UE in a WLAN user plane gateway (WUPG), enabling the WUPG to act as a gateway for the offloaded data flow associated with the UE.

Description

INTEGRATION OF NON-3GPP ACCESS

IN A 5G SYSTEM USER PLANE FRAMEWORK

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional

Application No. 62/279,351, filed January 15, 2016, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] There are emerging requirements for new mobile telecommunication services including very low delay, high reliability, and services to support massive numbers of devices, to name only a few. These services and their requirements cannot be met, at least not fully, by existing mobile communication systems (for example, Long Term Evolution (LTE), Universal Mobile Telecommunications Service (UMTS), and the like). Several standards development organizations (for example, Next Generation Mobile Networks (NGMN), Third Generation Partnership Project (3GPP)) have begun investigating new communication systems that will provide the enablers to meet the new service requirements. This new system is generally referred to as a 5G system.

[0003] In addition to the desire for a 5G system to provide a framework for services requiring very low latency and high reliability, the system should also leverage techniques that will likely reduce operator cost and enable an efficient deployment and management of network functions and services. Examples of techniques that may be beneficial to a 5G system include Network Function Virtu alization (NFV), Software Defined Networks (SDN), O enFlow, and the like.

[0004] The 3GPP standards development organization has identified the current architectural requirements for a 5G system to include the following. The new 5G system will support a new 5G radio access technology (which is yet to be defined), as well as LTE and evolved LTE, and non 3GPP access types (such as wireless local area networks (WLANs) based on the Institute for Electronics and Electrical Engineers (IEEE) 802.11 standards, also known as WiFi). The new 5G system will support a unified authentication framework for different access systems. The new 5G system will support multiple simultaneous connections of a user equipment (UE) via multiple access technologies. The new 5G system will allow independent evolutions of the core network and the radio access network (RAN). The new 5G system will support a separation of Control plane (CP) and User plane (UP) functions. The new 5G system will support Internet protocol (IP) connectivity services and connectivity services for data units other than IP. The new 5G system will leverage techniques (such as NFV and SDN) to reduce total cost of ownership, improve operational efficiency, energy efficiency, and simplicity and flexibility for offering new services. The new 5G system will support different levels of UE mobility (including stationary UEs). The new 5G system will support different levels of resilience for the services provided by the network. The new 5G system will support various ways to reduce UE power consumption. The new 5G system will support services that have different latency requirements between the UE and the packet data network (PDN). The new 5G system will minimize the signaling (and delay) required to commence traffic exchange between the UE and the PDN. The new 5G system will support network sharing, roaming (including routing of user traffic entirely via the visited pubhc land mobile network (VPLMN) and routing of the user traffic back to the home public land mobile network (HPLMN), broadcast services, and network slicing. The new 5G architecture will also support architecture enhancements for vertical applications and scale-in/scale-out.

[0005] Thus far, no solution exists that enables the above requirements.

SUMMARY

[0006] A control plane (CP) node is described for offloading a data flow associated with a user equipment (UE) to an IEEE 802.11 wireless local area network (WLAN). The CP node includes an offload processor that is configured to determine to initiate offload of the data flow associated with the UE to the WLAN. The CP node includes at least one interface configured to transmit a non-access stratum (NAS) message to the UE to commence offload of the data flow associated with the UE to the WLAN. The at least one interface is further configured to update a context associated with the UE in a WLAN user plane gateway (WUPG), enabhng the WUPG to act as a gateway for the offloaded data flow associated with the UE.

[0007] Additionally, the CP node may instruct a radio access network

(RAN) node associated with the UE to begin offload of the data flow associated with the UE to the WLAN. The CP node may receive a confirmation from the RAN node that measurements performed by the UE associated with the WLAN support the offload of the data flow associated with the UE to the WLAN. The offload processor may determine to initiate data flow offload to the WLAN based on at least one of a UE associated with the data flow, a quality of service (QoS) associated with the data flow, an application identifier associated with the data flow, an Internet protocol (IP) address associated with the data flow, or a media type associate with the data flow.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0009] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0010] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;

[0011] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;

[0012] FIG. 2 is a diagram of a 5G system architecture;

[0013] FIG. 3 is a block diagram of a WUPG;

[0014] FIG. 4 is a method flow diagram of UE initiated WiFi offload; and [0015] FIG. 5 is a method flow diagram of network initiated WiFi offload.

DETAILED DESCRIPTION

[0016] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0017] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0018] The communications systems 100 may also include a base station

114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0019] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple -input multiple-output (MIMO) technology and, therefore, may utihze multiple transceivers for each sector of the cell.

[0020] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication hnk (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0021] More specifically, as noted above, the communications system

100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High- Speed Downhnk Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0022] In another embodiment, the base station 114a and the WTRUs

102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may estabhsh the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A). [0023] In other embodiments, the base station 114a and the WTRUs

102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0024] The base station 114b in FIG. 1A may be a wireless router, Home

Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0025] The RAN 104 may be in communication with the core network

106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high- level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0026] The core network 106 may also serve as a gateway for the

WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0027] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular -based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0028] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display /touchp ad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0029] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0030] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0031] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0032] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0033] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128 (e.g., a liquid crystal display (LCD) display unit or organic hght-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The nonremovable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0034] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0035] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0036] The processor 118 may further be coupled to other peripherals

138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0037] FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0038] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0039] Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0040] The core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0041] The MME 142 may be connected to each of the eNode-Bs 140a,

140b, 140c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0042] The serving gateway 144 may be connected to each of the eNode

Bs 140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0043] The serving gateway 144 may also be connected to the PDN gateway 146, which may provide the WTRUs 102a, 102b, 102c with access to packet -switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0044] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0045] Other network 112 may further be connected to an IEEE 802.11 based wireless local area network (WLAN) 160. The WLAN 160 may include an access router 165. The access router may contain gateway functionality. The access router 165 may be in communication with a plurality of access points (APs) 170a, 170b. The communication between access router 165 and APs 170a, 170b may be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol. AP 170a is in wireless communication over an air interface with WTRU 102 d.

[0046] A new 5G system that includes support for IEEE 802.11 based radio access technologies (RATs), also referred to herein as WiFi access or simply WiFi, is herein described. This new architecture allows a WiFi RAT to be "plugged" into the user plane framework in an efficient manner. The architecture leverages techniques such as SDN and OpenFlow, or other similar protocols or techniques that might be used in current or future systems.

[0047] Further, several methods are described for using the WiFi RAT as a way to access the 5G user plane framework. For example, a WiFi User Plane Gateway (WUPG) is described that acts as an aggregator for all the WiFi access points that can be deployed in the new 5G system. The WUPG may be deployed per access point (AP) or per a 5G RAN node such as an eNB or any similar node that may be devised for a 5G system. Moreover, the 5G system's control plane node(s) may use techniques such as, but not limited to, OpenFlow (or any other similar protocol), to forward the routing rules to the WUPG so that packets are correctly forwarded within the 5G system, optionally with a particular Quality of Service (QoS) or Quality of Experience (QoE).

[0048] Figure 2 shows an example of a system architecture 200 for use in the new 5G system that meets the requirements identified above. One of the key nodes in this new system 200 is the WUPG 210. The WUPG 210 will be described in much greater detail below after the other components of the architecture are described.

[0049] The Registration Entity (RE) 220 is a node in the system 200 that handles the registration of devices and UEs. This includes performing authentication and security operations. The RE 220 is also responsible for idle mode mobility and paging. This RE 220 may perform similar functions such as, but not limited to, the MME and SGSN in the LTE and UMTS systems. The evolved serving gateway control plane (eSGW-CP) node 230 is the control portion of a user plane node such as the SGSN or SGW nodes. The eSGW-CP 230 stores forwarding rules for IP packets and loads these rules to the purely user plane (UP) nodes that only forward packets based on the rules (these UP nodes will be discussed below). The eSGW-CP 230 communicates the routing and forwarding rules via protocols such as, but not limited to, OpenFlow. In the system 200 of Figure 2, there is a single eSGW-CP node 230 shown, but this is exemplary and multiple may exist in the system 200. [0050] The evolved serving gateway user plane (eSGW-UP) node 240 is a node that routes IP flows according to particular QoS requirements of each IP flow. In the system 200 of Figure 2, there is a single eSGW-UP node 240 shown, but this is exemplary and multiple may exist in the system 200. Each eSGW-UP node 240 handles packet routing for all UEs in the system 200, for example, on a per QoS basis and not on a per UE basis. The eSGW-UP nodes 240 receive the forwarding rules from the eSGW-CP 230. The eSGW-UP 240 is similar to the user plane component of the SGSN and the SGW.

[0051] The evolved packet gateway control plane (ePGW-CP) node 250 is similar to the eSGW-CP 230 and also contains the routing and forwarding rules for the devices and UEs for handling traffic in both directions: first from the system 200 to the Internet or Packet Data Network (PDN), and second for handhng incoming packets from the Internet or PDN destined inwards to the system 200. Moreover, the ePGW-CP 250 provides the routing and forwarding rules to the ePGW-UP nodes 260 so that the appropriate ePGW-UP nodes 260 are used for handling IP flows. The ePGW-CP 260 is similar to the control portion of the PGW and GGSN.

[0052] The evolved packet gateway user plane (ePGW-UP) nodes 260 perform a similar function as the eSGW-UP nodes, which is also similar to the UP component of the PGW and the GGSN.

[0053] Although the system 200 targets a 5G network design, the system and method described are also applicable to an LTE system deployed with separated user and control planes. Moreover, for the user plane framework, the disclosed methods and apparatus described apply regardless of the type of protocol that is used for setting up the user plane connection within the core network. The description assumes general tunnehng protocol user (GTP-U) as the connection or transport for the user plane nodes, however, this is just an example and any other transport or protocol that may be used.

[0054] As mentioned above, the WUPG 210 is an important node in the system 200. The following is a description of the WUPG 210, and how it interacts with the other components in the 5G system 200.

[0055] The WUPG 210 is a new node to which non-3GPP access points

(APs) 265 connect. The non-3GPP access and the WUPG 210 are connected via a new interface that can run any transport protocol over any appropriate physical connection. The WUPG 210 receives forwarding rules from the control plane nodes in the 5G system 200 such as the eSGW-CP 230 and/or the ePGW-CP 250.

[0056] The WUPG 210 is also connected to other UP nodes in the 5G system 200 such as the eSGW-UP 240 and ePGW-UP 260. The connection between these nodes can be the same as that between the 5G RAN and the UP nodes in the system 200. For example, this connection may be a GTP-U connection. The WUPG 210 may connect to the eSGW-UP 240 or directly to the ePGW-UP 260. For the connection between the WUPG 210 and the other UP nodes in the system 200, the connection may be per QoS for all UEs, or it may be one connection for all QoS types for all or a subset of UEs.

[0057] The WUPG 210 may also be the switch-point to enable an optimized path between devices that are using a non-3GPP access 265. That is, devices that are not in direct proximity to enable direct communication may use the non-3GPP access 265 to communicate. When devices that are associated with the non-3GPP access 265 are communicating amongst themselves, the data does not flow out of the 3GPP network. Instead, the WUPG 210 is responsible for forwarding packets from one device to another such that the switching point is implemented at the WUPG 210. Note that the other UP nodes (for example, the eSGW-UP 240) may also act as a control node for the WUPG 210. These UP nodes may do so based on indications received from the CP nodes such as the eSGW-CP 230 and the ePGW-CP 250. Details of this are discussed in greater detail below.

[0058] The WUPG 210 may also perform security procedures. For example, these security procedures may include integrity protection, integrity checking, ciphering, deciphering, or both, on the data received over the non- 3 GPP access 265.

[0059] The non-3GPP access 265 may send congestion related information (for example, high congestion, no congestion, and the like) to the WUPG 210. Alternatively, the WUPG 210 may be able to assess congestion based on the volume of traffic received from individual or a set of non-3GPP accesses 265. The WUPG 210 may then send a congestion notification to the CP nodes to indicate the congestion.

[0060] Referring to Figure 3, the WUPG 210 of Figure 2 is described in greater structural detail. The WUPG 210 includes a new interface 300 for communicating with non-3GPP accesses. The WUPG 210 further includes a control plane interface 310 for communicating with an eSGW-CP and an ePGW-CP, as described above. The WUPG 210 further includes a user plane interface 320 for communicating with an eSGW-UP and an ePGW-UP, as described above. It is noted that the control plane interface 310 and the user plane interface 320 may be implemented as a single interface. The WUPG 210 includes at least one processor 330 that is coupled to the control plane interface 310 and the user plane interface 320. The control plane interface 310 may receive routing rules from CP nodes such as the eSGW-CP 230 and the ePGW-CP 250. The processor 330 processes received routing rules and routes user plane data according to the routing rules. Storage 340 stores the received routing rules, and may be used to buffer data. The WUPG 210 also includes an offloading processor 350, which may be integrated with the processor 330. The offloading processor 350 performs offloading in accordance with the following methods.

[0061] There are two requirements for offloading data to the non-3GPP access; first, it must be determined that offload is required, and second, it must be determined which flows are to be offloaded. Once these determinations are made, a control plane (CP) node may then send forwarding rules to the WUPG 210 so that packets received from the non-3GPP access 265 will be forwarded to the correct node in the 5G system 200. Similarly, packets received from other UP nodes in the system will be forwarded correctly to the appropriate non-3GPP access 265 and eventually the UE.

[0062] WiFi offloading may occur in at least two scenarios. In the first scenario, a UE may have rules or setting in the UE itself that determine WiFi offloading is required. In the second scenario, the UE may receive an indication or command to perform WiFi offload from the network. Some of these rules may be received from an Access Network Discovery and Selection Function (ANDSF) server, or a Proximity Server, or any other server that may be defined for new services (for example, for vehicular services or communications) that control access network selection and offloading. The UE may also receive a measurement configuration from an associated RAN node to measure link metrics associated with WiFi APs and report these metrics back to the RAN. Based on this reporting, or based on other factors such as, for example, traffic load or QoS, the UE may determine that offload to a WiFi AP is required. Alternatively, the user may, via the UE's user interface, choose the applications or flows that are to be offloaded to WiFi (for example, streaming video services or application updates and/or downloads). As another alternative, the application client in the UE may receive a request from the application server to offload specific flows to WiFi (for example, streaming video services). When this occurs, the non-access stratum (NAS) or 3GPP stack may receive a request to offload data related to an application over WiFi. The offload information received from the higher layers may be an application ID, application class, or a particular media type, or a set of flow identifications. In all of these instances, in this embodiment the UE ultimately makes the determination that WiFi offload is required.

[0063] Referring now to Figure 4, a method 400 for use in UE determined WiFi offload is described. When the UE determines that WiFi offload is required (step 410), based on any combination of the methods above, the UE may send a NAS session management or mobility management message request (hereafter generally referred to a NAS message) to the 5G system (step 420). This NAS message may include a request for WiFi offload. Moreover, the UE may include in the NAS message the description of the data for which this request is sent (for example, an application ID, application class, a particular media type, or a set of flow identifications) and QoS information for which this request is sent. The UE may also indicate an identifier of the AP (for example, a medium access control (MAC) address) and optionally the identifier of the RAN node (for example, received via broadcast information) with which this AP is associated or under whose coverage this AP is located.

[0064] The CP node in the network (for example, the RE or the eSGW-

CP) may receive the NAS message for offload to WiFi. The CP node may first authorize the request based on subscription profile or local policies (step 430). The CP node may forward this request to another CP entity and may include all or a subset of the information received in the NAS message (step 440). For example, the RE may receive NAS message, perform authorization, and then send a connection modification request to another CP node (for example, the eSGW-CP). Once the connection modification request is at the final CP node, the final CP node may then determine the WUPG address that is necessary to contact for the offload (step 450). The final CP node then updates the UE context to reflect the WUPG address and other UP node's address (that will be affected by this connection modification request) and also the forwarding rules and the connection ID (for example, GTP-U connection) that will be needed for the offload. After UE context is updated, the final CP node sends the forwarding rules to the WUPG and provides the connection information (for example, the GTP-U identity) to be used per IP flow in the uplink (UL) direction (i.e., for data received from the AP at the WUPG that is to be forwarded to another UP node in the 5G system) (step 460). Similarly, the final CP node determines other UP nodes in the system that are affected by this connection modification request. The final CP node then contacts the affected UP nodes (for example, a eSGW-UP node or a ePGW-UP node) and provides the forwarding rules for a set of IP flows and/or QoS, and also provides the address to be used by the UP nodes for sending data to the WUPG in the downlink (DL) direction (step 470). The final CP node may then send a response to the first CP node that initially sent the connection modification request to indicate the result of the connection modification request (for example, success or failure). The final CP node that determines the success of the connection modification request, may then send a NAS response to the UE to indicate the result of the NAS request and the IP flows and/or QoS for which the request has been processed. A UE may receive a NAS response for WiFi offload with information about the result of the request and the address/ID of an AP, the flow information and QoS information for which the response is related to (step 480). The NAS message may also contain bearer ID information. The NAS message may also include an application ID, application class ID, media type, or the like. The UE may then determine to start offloading traffic based on the received NAS message. The affected data may be any data associated with the identified QoS, or it may be data that is identified by the received flow information or data that uses the identified bearer ID. The WUPG 210 finally acts as the gateway for UP data that has been offloaded to WiFi for delivery to the UE (step 490).

[0065] Note that after the offload to or from WiFi, the CP nodes may modify the connection for the 5G RAT and UP nodes. For example, if data is offloaded from the 5G system to WiFi, then the resources previously used in the 5G system may no longer be necessary and can be released. As such, the CP nodes may take the action to modify these resources accordingly and forward modified forwarding rules to the various UP nodes in the 5G system. Moreover, the CP nodes may send a NAS message to the UE to modify the connection over the 5G accordingly. In the second scenario discussed above, the network initiates the WiFi offloading. Referring now to Figure 5, a method 500 is shown where the UE may receive an indication or command to perform WiFi offload from the network. An Access Network Discovery and Selection Function (ANDSF) server, or a Proximity Server, or any other server that may be defined for new services (for example, for vehicular services or communications) that controls access network selection and offloading may be integral to the network offloading decision. The ANDSF, CP node, or other server makes the decision to perform WiFi offloading (step 510).

[0066] The ANDSF, CP node, or other server that made the WiFi offload decision may send an offload request to another CP via a well-known interface (message 512). The offload information may include a set of IP flows for offload, an application ID, application class, a particular media type, a QoS, or the like. The offload request may be sent for several devices that may be uniquely identified. A Service Capability Exposure Function (SCEF) may send an offload request to a CP. The offload request contains the requested action (for example, start offload, or stop offload). The offload information may include a set of IP flows for offload, an application ID, application class, a particular media type, a QoS, or the like. The SCEF may first check whether the request from the AS/AF can be authorized and it may map at least one external ID to an internal ID that uniquely identifies the UE in question. If the offload request is authorized, the SCEF forwards the offload request to a CP node (for example, an ePGW-CP, a eSGW-CP, or the RE).

[0067] Note that once a CP node receives the offload request, the CP node may in turn forward the offload request to another CP node that may be responsible for authorizing the offload request and taking the necessary actions for the offload (step 520).

[0068] The home subscriber server (HSS), or a node with similar functions, may forward updated subscription information to a CP node with updated information that reflects a device's permission to perform WiFi offload, or that a device is no longer permitted to perform WiFi offload (step 530). The updated information may contain any additional information previously listed such as a set of IP flows, the QoS for which this offload is directed, a set of application IDs, media types, and the like. This update sent from the HSS to a CP node may occur at any time during the method shown in Figure 5.

[0069] A network node (for example, a CP node such as the RE, the eSGW-CP, or a ePGW-CP) may determine to offload certain data, as previously described by IP flows, QoS, application ID, or any combination of these parameters, over WiFi. This same process may be applicable when the requested action required is to stop offload for a given device, or flow, or QoS, etc. Once determined, the CP node may send a request to the serving RAN node over the 5G system to request the RAN node to verify (for example, in terms of link conditions and measurements) if WiFi offload may be achieved for an identified UE, description of data type (for example, defined by QoS), IP flow description, or bearer ID, etc. (step 540). The CP node may also include an identity of the AP over which offload may be achieved.

[0070] When a RAN node receives a request to verify if offloading over

WiFi is possible, the RAN node may configure the UE for measurements of WiFi APs (step 550). Once the measurements are performed by the UE and reported back to the RAN node (step 560), the RAN node may determine, based on local configurations, thresholds, and rules, whether WiFi offload may be achieved (step 570). If it is determined that WiFi offload is possible, the RAN node may send an indication to the CP node to perform WiFi offload, and optionally to identify a specific WiFi AP (for example, using the MAC address of the AP) for the WiFi offload (message 575).

[0071] Once the determination to perform WiFi offload is made, the CP node may optionally forward an indication of the determination to another CP node, and the indication may include the data type to be offloaded (for example, QoS, IP flows, or other parameters previously listed). Finally, the CP node (for example, the RE, a eSGW-CP, or a ePGW-CP) that performs the final determination to offload may then send a NAS message to the UE confirming the WiFi offload (step 580). The NAS message (message 585) may include all the required information about the offload as previously described. The CP node may also determine an updated UE context for the purpose of setting up a connection between a WUPG and another UP node, as previously described. The CP node may then send forwarding rules to a chosen WUPG and a chosen UP node that will be used to route the offloaded data over WiFi (step 590). The WUPG may then route WiFi offloaded data via the user plane to the UE (step 595). Finally, a CP node may modify a connection over the 5G system due to the WiFi offload (for example, the CP node may release a connection or modify parts of a connection over the 5G system and RAT).

[0072] The NAS message indicating WiFi offload sent by a CP node to the UE may be sent via the serving 5G RAN node at the request of the CP node. Thus, once the CP node determines to perform WiFi offload (step 540), the CP node may send an offload request (start or stop offload) to a RAN node indicating a data type for which the request is sent (for example, the QoS, the set of IP flows, a connection ID (which implies all flows on that connection will now go over WiFi), and also an identifier of the UE for which the request is associated.

[0073] When a RAN node receives a request to start WiFi offload for a

UE, the RAN node may request the UE perform measurements, as described above. The RAN node may then determine that an offload action is required and as such send a request to the UE to take a particular offload action. For example, the RAN node may send a start offload request to a UE and also includes the data type for which this offload is requested as received from the CP node. [0074] In addition to the above described embodiments, the WUPG may perform security procedures using a set of parameters that are obtained from the 5G security parameter set that is used by the UE to communicate via the 5G system. The RAN node that a UE is communicating with may forward security parameters to a WUPG that may be used in connection with the WiFi offloaded data. Alternatively, a CP node may forward these parameters to the WUPG.

[0075] The RAN node and/or CP node may also forward an indication to the UE to use a well-defined set of security parameters or algorithms for the data that is WiFi offloaded. As such, both the UE and the WUPG will use the same security parameters that are derived from the 5G security parameters. Similarly, for any data received over WiFi, the UE uses the security parameters indicated by the network to perform the necessary security procedures, such as integrity check or deciphering, or both, for example.

[0076] Likewise, the WUPG is responsible for performing integrity checking and/or deciphering on received data in the UL direction, using any signaled security parameters or algorithms from a RAN node or a CP node. For DL data, the WUPG also uses the received security parameters or algorithms from a RAN node or a CP node to perform integrity protection and/or ciphering on the data that is sent over a WiFi connection.

[0077] The WUPG may be the switching point that enables an optimized path between devices that are using 3GPP or non-3GPP access. This may be beneficial for devices that are not in direct proximity to enable direct communication, and they may therefore use the non-3GPP APs to communicate, or for devices that are connected to different non-3GPP APs but those non-3GPP APs are connected to the same WUPG. In these cases, data flows between the devices do not need to flow through the 3GPP core network (i.e., user plane gateways (UPGWs) in the core network). Instead, the WUPG may act as a switching point for these data flows, preventing the flows from entering the 3GPP core network. The WUPG may be responsible for forwarding packets from one device to another such that the switching functionality may be enabled at the WUPG.

[0078] The CP nodes in the core network (for example, the Mobility

Management (MM) function or the Session Management (SM) function) may determine that a WUPG may act as a switching point, thereby creating an optimized path, for certain data flows. This decision by the CP node may be made based on one or multiple of the following consideration.

[0079] First, the CP nodes will consider data flows for UEs that may be traversing the same WUPG. Enablement of optimized path is possible if the data flows for different UEs for which the data is routed via the optimized path have a user plane connection through the same WUPG.

[0080] Second, indications from a UE upon connection establish, or sent at a time after connection establishment, may be consider. Such indications may provide information to the network that certain data flows for a particular application are peer-to-peer (P2P) flows. The indication may be in the form of an application ID, a data network name (DNN), or an explicit information element informing the network about the P2P characteristics of the data flow. These indications may be provided during the PDU connection establishment, an update of the PDU connection, or when updating QoS information during the lifetime of a PDU connection.

[0081] Third, a third party application server (AS) may request the network to establish an optimized path for a pair of UEs. The AS may provide the description of the data flows and/or the identity of the UEs to the CP nodes. Information from the AS may be provided either via an exposure function or via direct interface between the AS and the CP nodes. In the latter case, the direct interface may be between the AS and the policy function/node or between AS and the session management function in the control plane.

[0082] Fourth, the user plane gateway(s) in the data path may inform the CP nodes when data flows are observed which exhibit P2P characteristics. Such determination may be made by the UPGWs based on traffic detection functionality. It is possible that the UPGW may be explicitly requested by the CP node to perform traffic detection and report back to the CP node in response to the request.

[0083] Before making a final decision to enable optimized path for a set of UEs, the network may check the subscription profile of each of the UEs involved. Information from the subscription profile may determine whether the UE is permitted to participate in an optimized data path.

[0084] The WUPG may then be configured by the CP node to redirect traffic destined for another UE in the optimized path without having the data flow enter the core network. The CP nodes may send the traffic description for which the optimized path needs to be activated. The traffic description may be in the form IP 5-tupple of the uplink traffic. The CP nodes may send uplink traffic descriptors for all UEs for which the optimized path is enabled. At the initial establishment of the optimized path, at least two traffic descriptors may be sent to the WUPG to enable optimized path for a pair of UEs. The CP nodes may send additional IP 5-tupples if an optimized path is created for more UEs. Traffic description information may be sent separately (i.e., in a separate control message) to the WUPG for each UE and possibly on a per PDU connection basis.

[0085] If the WUPG has received an uplink traffic description or IP 5- tupple information from the CP node for a PDU connection, the WUPG may check the IP header of all the uplink packets on that PDU connection. IP headers matching the traffic description indicates that optimized path is enabled for that IP flow. Hence, the WUPG may not forward that packet to the UPGW in the core network. Instead, the WUPG may route the packet locally towards the destination UE via the non-3GPP access (i.e., a WiFi AP) node or the RAN node (for the case when the destination UE is connected to an eNB or 5GeNB and there is an interface between the WUPG and the 3GPP node).

[0086] After the WUPG determines that a certain packet needs to be routed via the optimized path, the WUPG may then determine the next hop (for example, non-3GPP AP or 3GPP RAN node) for the packet. In certain cases when the WUPG may already have packet forwarding rules, the WUPG checks the destination address in the uplink IP packet. The WUPG may further check if there are forwarding rule for the destination IP address in the downlink direction - there should be a downlink forwarding rule available at the WUPG if the destination UE is connected to the same WUPG. If such a forwarding rule exists at the WUPG, the WUPG would then determine the next hop, or the non-3GPP AP, which is serving the UE.

[0087] In the case when the destination UE is connected to a 3GPP node

(for example, an eNB or a 5gNB), the CP node may send additional information about the next hop when configuring the optimized path. Such extra information may include the PDU session ID, QoS parameters, and identification information of the 3GPP node (for example, the eNB ID) which is serving the UE. The WUPG may determine the next hop based on this 3GPP node identification information. When the WUPG forwards the packet to the 3 GPP node, the WUPG may include PDU session ID and QoS parameters in the packet so that an eNB may map the packet to the appropriate radio bearer.

[0088] In another embodiment, the CP node may assign a local or a new

IP address to the UE when the CP node determines to enable optimized path for the UE. This new IP address may be sent to the UE via a NAS message, possibly a SM PDU connection update message. The UE may use this new IP address for the P2P traffic that is routed via the optimized path. The network may explicitly indicate the UE is required to use this new IP address as part of the NAS message providing the new IP address to the UE. Upon configuring the optimized path, the CP node provides the new IP address to the WUPG. The WUPG may then inspect the uplink packet header for a match of the new IP address (the UE would use the new IP address as the source address for packets destined for the optimized path). If an uplink packet source IP address matches the new IP address, the WUPG routes the packet via the optimized path. Forwarding rules may also be configured at the WUPG by the CP node when the new IP address is assigned to the UE. The WUPG may route data flows based on these configured forwarding rules.

[0089] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

^• * *

Claims

CLAIMS What is claimed

1. A method for use in a fifth generation (5G) core network control plane (CP) node for offloading a data flow associated with a user equipment (UE) to an IEEE 802.11 wireless local area network (WLAN), the method comprising:

determining to initiate offload of the data flow associated with the UE to the WLAN;

transmitting a non-access stratum (NAS) message to the UE to commence data flow offload to the WLAN; and

updating a context associated with the UE in a WLAN user plane gateway (WUPG), thereby enabling the WUPG to act as a gateway for the offloaded data flow associated with the UE.

2. The method of claim 1, further comprising:

instructing a radio access network (RAN) node associated with the UE to begin offload of the data flow associated with the UE to the WLAN.

3. The method of claim 2, further comprising:

receiving a confirmation from the RAN node that measurements performed by the UE associated with the WLAN support the offload of the data flow associated with the UE to the WLAN.

4. The method of claim 1, wherein the determining to initiate data flow offload to the WLAN is based on a rule set received from another CP node.

5. The method of claim 1, wherein the determining to initiate data flow offload to the WLAN is based on at least one of a UE associated with the data flow, a quality of service (QoS) associated with the data flow, an application identifier associated with the data flow, an Internet protocol (IP) address associated with the data flow, or a media type associate with the data flow.

6. The method of claim 1, wherein the NAS message includes information identifying the data flow to be offloaded.

7. The method of claim 1, further comprising:

transmitting to the RAN node an instruction to release resources associated with the UE after data flow offload to the WLAN has begun.

8. The method of claim 1, wherein determining to initiate data flow offload to the WLAN includes determining whether a subscription associated with the UE permits data flow offload.

9. The method of claim 1, wherein the CP node is a registration entity (RE) node, an evolved serving gateway control plane (eSGW-CP) node, or an evolved packet gateway control plane (ePGW-CP) node.

10. The method of claim 1, further comprising:

transmitting security parameters to the WUPG to enable security of the data flow associated with the UE that is offloaded to the WLAN.

11. A control plane (CP) node for offloading a data flow associated with a user equipment (UE) to an IEEE 802.11 wireless local area network (WLAN), the CP node comprising:

an offload processor configured to determine to initiate offload of the data flow associated with the UE to the WLAN;

at least one interface is configured to transmit a non-access stratum (NAS) message to the UE to commence offload of the data flow associated with the UE to the WLAN; and

the at least one interface further configured to update a context associated with the UE in a WLAN user plane gateway (WUPG), thereby enabling the WUPG to act as a gateway for the offloaded data flow associated with the UE.

12. The CP node of claim 11, wherein the at least one interface is further configured to instruct a radio access network (RAN) node associated with the UE to begin offload of the data flow associated with the UE to the WLAN.

13. The CP node of claim 12, wherein the at least one interface is further configured to receive a confirmation from the RAN node that measurements performed by the UE associated with the WLAN support the offload of the data flow associated with the UE to the WLAN.

14. The CP node of claim 11, wherein the offload processor is configured to determine to initiate data flow offload to the WLAN based on a rule set received from another CP node.

15. The CP node of claim 11, wherein the offload processor is configured to determine to initiate data flow offload to the WLAN based on at least one of a UE associated with the data flow, a quality of service (QoS) associated with the data flow, an application identifier associated with the data flow, an Internet protocol (IP) address associated with the data flow, or a media type associate with the data flow.

16. The CP node of claim 11, wherein the NAS message includes information identifying the data flow to be offloaded.

17. The CP node of claim 11, wherein the at least on interface is further configured to transmit, to the RAN node, an instruction to release resources associated with the UE after data flow offload to the WLAN has begun.

18. The CP node of claim 11, wherein the offload processor is further configured to determine to initiate data flow offload to the WLAN based on whether a subscription associated with the UE permits data flow offload.

19. The CP node of claim 11, wherein the CP node is a registration entity (RE) node, an evolved serving gateway control plane (eSGW-CP) node, or an evolved packet gateway control plane (ePGW-CP) node.

20. The CP node of claim 11, wherein the at least one interface is further configured to transmit security parameters to the WUPG to enable security of the data flow associated with the UE that is offloaded to the WLAN.