WO2019010702A1

WO2019010702A1 - Access traffic steering, switching, and splitting management

Info

Publication number: WO2019010702A1
Application number: PCT/CN2017/093007
Authority: WO
Inventors: Xingyue Zhou; Xiaoyun Zhou
Original assignee: Zte Corporation
Priority date: 2017-07-14
Filing date: 2017-07-14
Publication date: 2019-01-17

Abstract

A method and apparatus for access traffic steering, switching, and splitting are disclosed. In one embodiment, a method includes: establishing a connection between a user equipment and a core network; establishing a first subflow and a second subflow to transfer an ongoing data flow through a first type communication link and a second type communication link, respectively; providing connection information concerning the first subflow and the second subflow to the core network; and based on the connection information, adjusting the first and second subflows to provide an adjusted data flow.

Description

ACCESS TRAFFIC STEERING, SWITCHING, AND SPLITTING MANAGEMENT

TECHNICAL FIELD

The disclosure relates generally to wireless communications and, more particularly, to systems and methods for access traffic steering, switching, and splitting between different types of access links.

BACKGROUND

As the number of applications and services for digital data continues to increase, the demands and challenges placed on network resources and operators will also continue to increase. Being able to deliver a wide variety of network performance characteristics that future services will demand is one of the primary technical challenges faced by service providers today. The performance requirements placed on the network will demand connectivity in terms of data rate, latency, QoS, security, availability, and many other parameters, all of which will vary from one service to the next. Thus, enabling a network to allocate resources in a flexible manner to provide customized connectivity for each different type of service will greatly enhance the network’s ability to meet future demands.

As used herein, the term "network" or "communication network" refers to infrastructure resources provided by a network operator to provide data communication services, which may include both wired and wireless services, to customers of the network operation. Examples of such network operators include AT&T, Verizon, Sprint, Vodafone, etc. Such a network may include a core portion, a radio access network (RAN) portion and a backhaul portion, for example. The network may further comprise various virtualized resources and functions as would be understood by persons of ordinary skill in the art. As these networks adopt the next generation network standards (i.e., 5G) , referred to as “5G networks, ” they will become capable of dynamic reconfigurations, as described in further detail below.

According to the definition in the 3^rd Generation Partnership Project (3GPP) technical specification (TS) 23.501, a 5G system architecture may support data connectivity and services enabling deployments to use techniques and a variety of functions such as network function virtualization (NFV) and software defined networking (SDN) , for example. The 5G system architecture may also leverage service-based interactions between control plane (CP) network functions where identified.

Figure 1 is a block diagram 100 that illustrates a typical 5G communication system. The 5G communication system may include the following network functions: user equipment (UE) 102, (radio) access network (RAN) 104, access and mobility management function (AMF) 106, user plane function (UPF) 108, data network (DN) 110, session management function (SMF) 112, authentication server function (AUSF) 114, unified data management (UDM) 116, policy control function (PCF) 118, and application function (AF) 120. The UE 102 may be any device, apparatus or system operated by a user or client entity such as a mobile phone, laptop computer, wireless sensor (s) , and the like. The RAN 104 may be an intermediary between the core network and the UE 102. The AMF 106 may manage access control and mobility for the UE 102 relative to the core network and 5G communication system. The UPF 108 may be a function that creates data packets to carry network traffic in accordance with protocols such as the transmission control protocol (TCP) , user datagram protocol UDP, and internet protocol (IP) . The DN 110 may include resources (e.g., data) that the UE 102 may seek to retrieve by accessing the 5G communication system. The SMF 112 may be a function that sets up and manages sessions on the 5G communication system according to network policy. The AUSF 114 may authenticate of credentials for the 5G communication system. The UDM 116 may be a centralized computing system, or a function, for collecting, integrating, and managing large sets of structured and unstructured data from disparate sources. The PCF 118 may provide and manage a policy framework for the 5G communication system. The AF 120 may also be referred to interchangeably as an application server (AS) herein and may provide various services for the UE 102 that the UE 102 may access through the 5G communication system. Each of the network functions may be interconnected and/or fed back on itself via network interfaces N1-N15, as shown in Figure 1.

As used herein, the term “function” , or “network function” refers to one or more virtual functions performed by one or more physical resources of a network, which are configured to perform the corresponding function. Such physical resources can include one or more processors, computers, servers, memories, databases, communication interfaces, etc. that may be co-located in a single network communication node or distributed among multiple nodes. Persons of ordinary skill in the art would be familiar with how the “functions” discussed herein can be implemented via hardware, firmware, software or any combination of these techniques.

A non-3GPP access link refers to access technologies that are not within the scope of 3GPP technical specifications. Such non-3GPP access technologies include technologies such as Wi-Fi and WLAN access protocols, for example. Those of ordinary skill in the art readily understand what constitutes a non-3GPP access technology. Non-3GPP access links may be a companion access infrastructure for mobile networks that can help mobile operators deal with the explosive rate of growth in network traffic. Non-3GPP access links, such as an access link via Wi-Fi or wireless local area networks (WLAN) , can relieve the pressure of increased network traffic on a mobile network and can offer fast indoor data connections. Also, as will be discussed below, the 5G core network (CN) may support connectivity of a UE via standalone non-3GPP access networks (e.g. WLAN access) .

Figure 2 is a block diagram of a system 200 in which non-3GPP access links may access a 5G core network. A 5G core network may be any set of functions within the 5G network that routes information within the 5G network, such as between a UE 202 and an application function 204 or data network 206. For example, the 5G core network may include at least an AMF 208, UPF 210, and an SMF 212, having the corresponding functions discussed above with respect to Figure 1. The system 200 further includes a PCF 214 and a network exposure function (NEF) 216, each coupled to the AF 204. The NEF 216 publishes and helps provides exposure for network data. The non-3GPP access links (e.g., access network) to the 5G core network may be either trusted 220 or untrusted 222, as dependent upon related operator policies. For example, whether a non-3GPP internet protocol (IP) access link is trusted 220 or untrusted 222 may not be a characteristic of the non-3GPP IP access link. Rather, in a non-roaming scenario, whether a non-3GPP IP access link is trusted 220 or untrusted 222 may be arbitrarily set by an operator of a home public land mobile network (HPLMN) operator. Also, in a roaming scenario, the home subscriber server (HSS) /3GPP authentication, authorization, and accounting (AAA) server in HPLMN may make a determination as to whether a non-3GPP IP access link is used as a trusted 220 or untrusted 222 non-3GPP access link. The HSS /3GPP AAA server may take the visited public land mobile network (VPLMN) policy and capability returned from the 3GPP AAA proxy or roaming agreement into account for this determination.

For supporting multiple packet data networks (PDN) , the same trust relationship may apply to all the PDNs the UE connects to from a certain non-3GPP access link. For example, a single PDN may be associated as either a trusted or untrusted non-3GPP access link (and not be associated with both a trusted and untrusted non-3GPP access link. ) Untrusted non-3GPP access networks 222 can be connected to the 5G core network via a non-3GPP InterWorking Function (N3IWF) 224, as known in the art. Trusted non-3GPP access networks 220 can be connected to the 5G core network (CN) via the N2 interface between the UE and AMF. The N2 and N3 interfaces may be used to connect standalone non-3GPP access and/or N3IWF 224 to the 5G Core Network control-plane functions (e.g., AMF functions 208) and user-plane functions (e.g., UPF 210) , respectively.

Increasingly, many operators are seeking ways to balance data traffic between mobile networks (e.g., 3GPP access links) and non-3GPP access links in a way that is transparent to users and reduces mobile network congestion. This can be achieved by not only steering traffic from the mobile network onto non-3GPP access links, but also by switching or splitting traffic in a managed way between the two types of accesses (e.g., 3GPP and non-3GPP) in order to deliver the best customer experience. Operators can benefit by using their emerging 5G core network for harmonized traffic handling across 3GPP and non-3GPP access links. For UEs that can be simultaneously connected to both 3GPP access links and non-3GPP access links, the 5G system may be able to take advantage of these multiple access links in a way that improves the user experience, optimizes the traffic distribution across various access links, and enables the provision of new high-data-rate services.

Access traffic steering, switching and splitting (ATSSS) may be utilized as configurations for communications using 3GPP and/or non-3GPP access links. Access traffic steering may be a procedure that selects the "best" access link network (e.g. 3GPP access link or non-3GPP access link, such as WLAN) for a new data flow and transfers the traffic of this new data flow over the selected "best" access link network. The selection of the "best" access link network is typically based on criteria such as the network load, the measured radio signal quality, the application associated with the data flow, etc.

Access traffic switching may be a procedure that moves all traffic of an ongoing data flow from one access link network to another access link network (e.g., between 3GPP and non-3GPP access link networks) in a way that maintains the continuity of the data flow. For example, access traffic switching may switch an ongoing data flow from 3GPP to non-3GPP access links or from non-3GPP to 3GPP access links.

Access traffic splitting may be a procedure that splits the traffic of an ongoing data flow across multiple access link networks (e.g., between 3GPP and non-3GPP access links) . When traffic splitting is applied to a data flow, some traffic of the data flow is transferred via one access link (e.g., 3GPP or non-3GPP access links) and some other traffic of the same data flow is transferred via another access link (e.g., non-3GPP or 3GPP access links) .

A multipath transfer control protocol (MPTCP) may enable simultaneous use of several IP-addresses/interfaces by a modification of transmission control protocols (TCP) that presents a regular TCP interface to applications, while in fact spreading data across several subflows or paths in a way that is transparent to a user. Additionally, multipath TCP can present the same socket interface as TCP. This implies that MPTCP can be used with any standard TCP application to transparently spread application data across several subflows.

Figure 3 is a block diagram of a system 300 that can perform MPTCP data transfer. The host 302 may be any device, such as a UE device, that communicates with a remote server 304. Each of the host 302 and the remote server 304 may have a MPTCP module 305. A first subflow 306A (e.g., TCP subflow 1) and a second subflow 306B (TCP subflow 2) belong to the same TCP connection from the perspectives of both the host 302 and the remote server 304. In other words, the first and

second subflows

306A and 306B are each configured to carry at least a portion of the data flow of the TCP connection or application. The first subflow 306A transmits data through a 3GPP access link 308A while the second subflow 306B transmits data through a WLAN access link 308B (e.g., a non-3GPP access link) . The related traffic may be transferred over the first subflow 306A and the second subflow 306B at the same time or over one of the subflows at a time (e.g., all the traffic may be conveyed via the first subflow 306A and second subflow 306B may standby as a backup in case the first subflow 306A fails) based on local routing policies. However, traditional MPTCP data transfer techniques are unable to dynamically reconfigure a data flow across 3GPP and non-3GPP access networks. Therefore traditional communications using 3GPP and non-3GPP access networks are not entirely satisfactory.

SUMMARY OF THE INVENTION

The exemplary embodiments disclosed herein are directed to solving the issues relating to one or more of the problems presented in the prior art, as well as providing additional features that will become readily apparent by reference to the following detailed description when taken in conjunction with the accompany drawings. In accordance with various embodiments, exemplary systems, methods, devices and computer program products are disclosed herein. It is understood, however, that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art who read the present disclosure that various modifications to the disclosed embodiments can be made while remaining within the scope of the invention.

In one embodiment, a method includes: establishing a connection between a user equipment and a core network； establishing a first subflow and a second subflow to transfer a data flow through a first type communication link and a second type communication link, respectively； providing connection information concerning the first subflow and the second subflow to the core network； and based on the connection information, adjusting the first and second subflows to provide an adjusted data flow.

In a further embodiment, a method includes: establishing a connection between a user equipment and a core network； receiving connection information concerning a first subflow and a second subflow, wherein the first subflow and the second subflow transfer a data flow through a first type communication link and a second type communication link, respectively； generating an instruction signal for adjustment of the first and second subflows to provide an adjusted data flow； and sending the instruction signal to the user equipment.

In another embodiment, an apparatus includes: a transceiver； and at least one processor configured to: establish, using the transceiver, a connection between a user equipment and a core network； establish, using the transceiver, a first subflow and a second subflow to transfer a data flow through a first type communication link and a second type communication link, respectively； provide, using the transceiver, connection information concerning the first subflow and the second subflow to the core network； and based on the connection information, adjust, using the transceiver, the first and second subflows to provide an adjusted data flow.

In yet another embodiment, a system includes: at least one transceiver； and at least one processor configured to: establish, using the at least one transceiver, a connection between a user equipment and a core network； receive, using the at least one transceiver, connection information concerning a first subflow and a second subflow, wherein the first subflow and the second subflow transfer a data flow through a first type communication link and a second type communication link, respectively； generate an instruction signal for adjustment of the first and second subflows to provide an adjusted data flow； and send, using the at least one transceiver, the instruction signal to the user equipment.

BRIEF DESCRIPTION OF THE DRAWINGS

Various exemplary embodiments of the invention are described in detail below with reference to the following Figures. The drawings are provided for purposes of illustration only and merely depict exemplary embodiments of the invention to facilitate the reader's understanding of the invention. Therefore, the drawings presented herein should not be considered limiting of the breadth, scope, or applicability of the invention. It is also noted that for clarity and ease of illustration, the drawings are not necessarily drawn to scale.

Figure 1 is a block diagram that illustrates a conventional 5G communication system.

Figure 2 is a block diagram that illustrates a how non-3GPP access networks may conventionally access a 5G core network.

Figure 3 is a block diagram that illustrates an example of conventional MPTCP data transfer.

Figure 4 is a block diagram of a UE communicating with a core network via a MPTCP protocol, in accordance with some embodiments of the invention.

Figure 5 is a block diagram of a communication node, in accordance with some embodiments of the invention.

Figure 6 illustrates a method of an application server providing active flow information to a core network, in accordance with some embodiments of the invention.

Figure 7 is a block diagram of an ATSSS policy information data structure, in accordance with some embodiments.

Figure 8 illustrates a method of a UE providing active flow information to a core network, in accordance with some embodiments of the invention.

Figure 9 illustrates a method of either and/or both a UE and an application server providing active flow information to a core network, in accordance with some embodiments of the invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Various exemplary embodiments of the invention are described below with reference to the accompanying figures to enable a person of ordinary skill in the art to make and use the invention. As would be apparent to those of ordinary skill in the art, after reading the present disclosure, various changes or modifications to the examples described herein can be made without departing from the scope of the invention. Thus, the present invention is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the specific order or hierarchy of steps in the methods disclosed herein are merely exemplary approaches. Based upon design preferences, the specific order or hierarchy of steps of the disclosed methods or processes can be re-arranged while remaining within the scope of the present invention. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in a sample order, and the invention is not limited to the specific order or hierarchy presented unless expressly stated otherwise.

As described below, the operations illustrated in Figure 4-8 may refer to functional entities, such as UE, AMF, RAN, SMF, UPF, etc. (either in physical or virtual form) , which are similar to those mentioned above with respect to conventional networks as well as 3GPP and non-3GPP access links. As would be understood by persons of ordinary skill in the art, however, such conventional functional entities do not perform the functions described below, and therefore, would need to be modified or specifically configured to perform one or more of the operations described below. Additionally, persons of skill in the art would be enabled to configure functional entities to perform the operations described herein after reading the present disclosure. The term “configured” as used herein with respect to a specified operation or function refers to a system, device, component, circuit, structure, machine, signal, etc. that is physically or virtually constructed, programmed and/or arranged to perform the specified operation or function.

Systems and methods in accordance with various embodiments may provide for dynamic reconfigurations of access traffic steering, splitting, and switching for MPTCP based communications. For simplicity of discussion, reference to access traffic steering, access traffic, splitting, and access traffic splitting may be termed individually as an access traffic configuration and collectively as access traffic configurations or ATSSS. Each of the access traffic configurations are discussed above individually and will not be repeated here for brevity.

TCP-based application traffic may constitute an increasing amount of the traffic flow across the Internet. Accordingly, MPTCP may be an efficient approach to carry out TCP-based access traffic configurations (e.g., access traffic steering, switching and/or splitting) . However, traditional MPTCP may not provide the flexibility to dynamically reconfigure (e.g., adjust) access traffic configurations for an ideal configuration of access traffic configurations based upon connection information, such as active flow information. For example, traditionally, MPTCP may provide for communication in accordance with one of the access traffic configurations, but cannot dynamically reconfigure MPTCP communications among the different access traffic configurations (e.g., to adjust or change from traffic switching to traffic splitting and vice versa) for a particular data flow and/or subflow.

Advantageously, in certain embodiments, access traffic configurations may be dynamically reconfigured to provide an optimized configuration, or at least an improved configuration, of access traffic configurations for a particular data flow and/or subflow. For example, certain types of data may be more effectively transmitted across either or both 3GPP access links and non-3GPP access links in different situations. These situations may themselves may be dynamic and change over time as the data is transmitted (e.g., while a UE is moving into and out of indoor environments) . Accordingly, access traffic configurations may be dynamically reconfigured to meet the demands of these different situations as they arise during transmission of a data flow, in accordance with various embodiments of the invention.

As will be discussed further below, access traffic configurations may be established based on MPTCP connection information. MPTCP connection information may characterize MPTCP based communications between a UE and an application server (e.g., an application function) . For example, MPTCP connection information between a UE and an application server may be provided to a core network by the application server or the UE. The MPTCP connection information between the UE and the application server includes any combinations of the following elements: 5-tuple information for at least two subflows (e.g., a subflow 1 and a subflow 2) , a token (e.g., a unique identifier of an MPTCP connection between a UE and application server) , an MPTCP connection corresponding application identifier (ID) (e.g., an ID for an application that may utilize the MPTCP connection, such as the WeChat social media application, the online payments application PayPal, the Siri intelligent personal assistant, and the like) . The 5-tuple information may refer to a set of five different values that comprise a transmission control protocol/Internet protocol (TCP/IP) connection. These five values may include: a source IP address, destination IP address, source user datagram protocol (UDP) /TCP port number, destination UDP/TCP port number, and transport layer protocol type (TCP, UDP, Internet control message protocol (ICMP) , etc) .

As discussed above, MPTCP may enable simultaneous use of several IP-addresses/interfaces by a modification of transmission control protocols (TCP) that presents a regular TCP interface to applications, while spreading a data flow across several (e.g., at least two) subflows or paths. These at least two subflows may include at least a first subflow that transports part of a data flow over a 3GPP access link and a second subflow that transports part of the data flow over a non-3GPP access link.

Based on the MPTCP connection information received from the UE or application server, the core network may indicate to the UE and/or application server to communicate in accordance with a particular access traffic configuration. For example, the core network may indicate to (e.g., instruct) the UE and/or application server to move a data flow from a 3GPP access link to a non-3GPP access link or from a non-3GPP access link to a 3GPP access link (e.g., by performing access traffic steering) based on the received MPTCP connection information. Also, the core network may indicate to the UE and/or application server to have some traffic of the data flow transferred via a 3GPP access link and some other traffic of the same data flow transferred via a non-3GPP access link (e.g., by performing access traffic splitting) based on the received MPTCP connection information. The core network may also indicate whether the UE or application server should move an ongoing data flow from a 3GPP access link to a non-3GPP access link or from a non-3GPP access link to a 3GPP access link by sending a request to change the priority of subflow (s) or removing one subflow (e.g., by performing access traffic switching) based on the received MPTCP connection information.

In certain embodiments, the core network may determine MPTCP connection information (e.g., a TCP connection supporting MPTCP) based on receiving MPTCP support information, such as a MP_CAPABLE TCP indicator optionally included in a TCP synchronization message (e.g., a SYN packet) sent by the UE. The core network may retrieve the MPTCP connection information from a UE or application server based on the detected MPTCP support information.

Figure 4 is a block diagram 400 of a UE 402 communicating with a core network 404 via MPTCP, in accordance with some embodiments of the invention. The core network 404 may be a next generation (NG) core network. The UE 402 may host an application 405 (e.g., a MPTCP compatible application) that utilizes an MPTCP connection via an ATSSS client function 406 (CF) . The ATSSS CF 406 may call the MPTCP function 408 to create MPTCP flows for the application 405. Specifically, the ATSSS CF 406 may utilize a MPTCP function 408 for communications via a first subflow 410A (e.g., TCP subflow 1) and a second subflow 410B (e.g., TCP subflow 2) . The first subflow 410A may perform IP communications 412A over a 3GPP access link 414A. The second subflow 410B may perform IP communications 412B over a non-3GPP access link, such as a WLAN access link 414B.

The core network 404 may include an ATSSS network function 413 that may communicate with the ATSSS client function 406 on the UE 402. The ATSSS network function 413 may perform ATSSS management of the first subflow 410A and the second subflow 410B at the UE 402. The related ATSSS rules (e.g., flow description, routing information, priority, etc. ) may be provided by the PCF 414 of the core network 404. Also, MPTCP connection information from the application server 416 may be forwarded to the ATSSS network function via a PCF 414 of the core network 404. In other embodiments, the MPTCP connection information from the application server 416 may be forwarded to the ATSSS network function via a network exposure function (NEF) 418 (as indicated with dotted lines) and then via the PCF 414. In some embodiments, the PCF 414 and the NEF 418 are implemented as functions of the core network 404.

The UE 402 may engage in protocol data unit (PDU) sessions through 3GPP access links 414A and non-3GPPfne access links (e.g., WLAN access links 414B) at the same time. As shown in Figure 4, line 420A represents PDU sessions that are linked via the first subflow 410A and line 420B represents PDU sessions that are linked via the second subflow 410B. The first subflow 410A may be routed at the core network 404 by a first UPF 422A. Also, the second subflow 410B may be routed at the core network 404 by a second UPF 422B.

As discussed above, various types of functions or network functions may be performed by one or more physical resources of a network, which are configured to perform the corresponding functions. Such physical resources can include one or more processors, computers, servers, memories, databases, communication interfaces, etc. that may be co-located in a single networked communication node or distributed among multiple nodes.

In a wireless communication network, communication nodes may be any type of device, or physical resource that may be utilized for network communications. For example, communication nodes may be a user equipment (UE) , base station (BS) , access point (AP) or station (STA) . An AP may be the basic equipment in a wireless local area network (LAN) that establishes a basic service set (BSS) , and a station (STA) typically establishes wireless communications with the AP through a predetermined association or registration procedure, and thereafter communicates with the AP for data transmission. In some embodiments, an AP may also be equivalent to a base station (BS) and a STA be equivalent to a user equipment (UE) . In some types of networks such as ad-hoc networks, for example, an AP is typically not present in the network, and STA’s can communicate directly with each other and other nodes. Therefore, for both independent BSS (IBSS) and BSS, both STA’s and AP’s can generally be referred to as wireless communication nodes, or simply communication nodes, herein.

In various embodiments, the communication node can include, or be implemented as, a NodeB, radio network controller ( "RNC" ) , eNodeB, base station controller ( "BSC" ) , base transceiver station ( "BTS" ) , base station ( "BS" ) , transceiver function ( "TF" ) , radio router, radio transceiver, or some other communication node configured to perform the functions described herein. The term “configured for” or “configured to” as used herein with respect to a specified operation or function refers to a device, component, circuit, structure, machine, etc. that is physically constructed, programmed and/or arranged to perform the specified operation or function.

Various processes and methods can be used for transmissions in the wireless communication network between the communication nodes. For example, signals can be sent and received in accordance with orthogonal frequency division multiplexing (OFDM) /orthogonal frequency division multiple access (OFDMA) techniques, or code division multiple access (CDMA) techniques.

Figure 5 is a block diagram 500 of a communication node 502, in accordance with some embodiments of the invention. The communication node 502 is an example of a device that can be configured to implement the various methods described herein. The communication node 502 includes a housing 504 containing various modules such as a system clock 506, a processor 508, a memory 510, a transceiver 512 comprising a transmitter 514 and receiver 516.

The system clock 506 provides the timing signals to the processor 508 for controlling the timing of all operations of the communication node 502. The processor 203 controls the general operation of the communication node 502 and can include one or more processing circuits or modules such as a central processing unit (CPU) and/or any combination of general-purpose microprocessors, microcontrollers, digital signal processors (DSPs) , field programmable gate array (FPGAs) , programmable logic devices (PLDs) , controllers, state machines, gated logic, discrete hardware components, dedicated hardware finite state machines, or any other suitable circuits, devices and/or structures that can perform calculations or other manipulations of data.

The memory 510, which can include both read-only memory (ROM) and random access memory (RAM) , can provide instructions and data to the processor 508. A portion of the memory 510 can also include non-volatile random access memory (NVRAM) . The processor 508 typically performs logical and arithmetic operations based on program instructions stored within the memory 510. The instructions (a. k. a., software) stored in the memory 510 can be executed by the processor 508 to perform the methods described herein. The processor 508 and memory 510 together form a processing system that stores and executes software. As used herein, “software” means any type of instructions, whether referred to as software, firmware, middleware, microcode, etc. which can configure a machine or device to perform one or more desired functions or processes. Instructions can include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code) . The instructions, when executed by the one or more processors, cause the processing system to perform the various functions described herein.

The transceiver 512, which includes the transmitter 514 and receiver 516, allows the communication node 502 to transmit and receive data to and from another communication node. For wireless communications, an antenna 520 may be attached to the housing 504 and electrically coupled to the transceiver 512. However, in other embodiments, the transceiver may be utilized for wired connections without use of the antenna 520. In various embodiments, the communication node 502 include (not shown) multiple transmitters, multiple receivers, multiple transceivers, and/or multiple antennas. The transmitter 207 can be configured to wirelessly transmit packets having different packet types or functions, such packets being generated by the processor 203. Similarly, the receiver 209 is configured to receive packets having different packet types or functions, and the processor 203 is configured to process packets of a plurality of different packet types. For example, the processor 203 can be configured to determine the type of packet and to process the packet and/or fields of the packet accordingly.

The various modules discussed above are coupled together by a bus system 522. The bus system 522 can include a data bus and, for example, a power bus, a control signal bus, and/or a status signal bus in addition to the data bus. It is understood that the modules of the communication node 502 can be operatively coupled to one another using any suitable techniques and mediums.

Although a number of separate modules or components are illustrated in Figure 5, persons of ordinary skill in the art will understand that one or more of the modules can be combined or commonly implemented. For example, the processor 508 can implement not only the functionality described above with respect to the processor 508, but also implement the functionality described above with respect to the clock 506. Conversely, each of the modules illustrated in Figure 5 can be implemented using a plurality of separate components or elements.

Figure 6 illustrates a method of providing active flow information to a core network 604, in accordance with some embodiments of the invention. At operation 1, the UE 606 establishes an ATSSS connection to the core network 604. The ATSSS connection may be a connection in accordance with 3GPP protocols. At operation 2, the UE 606 and the core network 604 may exchange ATSSS policy information (e.g., control rules) via the ATSSS connection. In certain embodiments, the ATSSS policy information may be local to the UE 606 and transmitted to the core network 604 or may be remote to the UE 606 and received at the UE 606 from the core network 604. In further embodiments, the ATSSS policy information may include MPTCP connection information, as discussed above. In particular embodiments, the ATSSS policy information may include an instruction to perform access traffic steering. Examples of the ATSSS policy information will be discussed below in connection with Figure 7.

Referring still to Figure 6, at

operations

3A and 3B, according to local or network provided policy, the UE 606 may establish a first MPTCP subflow (e.g., subflow 1) and a second MPTCP subflow (e.g., subflow 2) to transfer a data flow through a 3GPP access link 608 and non-3GPP access link 610, respectively. Specifically, at operation 3A, the UE 606 establishes the first subflow with the application server via a 3GPP access link 608 with the application server 602. At operation 3B, the UE 606 establishes the second subflow via a non-3GPP access link 610 with the application server 602. In some embodiments, the first and second subflows may be implemented one after the other or, alternatively, simultaneously.

In certain embodiments, the core network 604 may determine MPTCP connection information (e.g., a TCP connection supporting MPTCP) based on receiving MPTCP support information, such as a MP_CAPABLE TCP indicator optionally included in TCP synchronization message (e.g., a SYN packet) sent by the UE 606 during a standard three-handshake exchange used in establishing one of the subflows in

operations

3A and 3B (e.g., when establishing the first subflow in operation 3A) . The three-handshake exchange used in establishing one of the subflows (e.g., the first subflow) may be performed as part of a standard TCP connection establishment procedure to negotiate and start a TCP connection between the UE 606 and the application server 602. As discussed above, a core network (e.g., core network 604 of Figure 6) may facilitate subflow communications via respective UPFs. Also, the core network 604 may retrieve the MPTCP connection information from the UE 606 or application server 602 based on the detected MPTCP support information.

At operation 4, the application server 602 provides active flow information to the core network 604. This active flow information may be provided 612 when there is a direct interface between the application server 602 and a PCF 612 via the PCF 612 or, optionally, a PCF 612 and NEF 614 (as illustrated with dotted lines) . Although the NEF 614 and the PCF 612 are illustrated as separate from the core network 604, the NEF 614 and the PCF 612 may be considered to be part of the core network 604 in certain embodiments. The active flow information may be a type of connection information, in accordance with some embodiments. The active flow information can include: 5-tuple information of MPTCP subflows, a token that is a unique identifier (ID) of the MPTCP connection between the UE and application server, and data flow information (e.g., data flow information related to UDP/TCP) . This data flow information may include parameters such as a data rate, error rate, or other parameters to determine how well communication under a particular subflow (and/or under a 3GPP access link 608 or a non-3GPP access link 610) is performing.

At operation 5, the core network 604 may instruct the UE 606 to dynamically reconfigure its access traffic configuration. This instruction or rules signal may be a radio signal that encodes a request, rule, or instruction decodable by the UE 606 and/or the application server 602 to perform a particular access traffic configuration. For example, in certain embodiments, the core network 604 may instruct the UE 606 to have some traffic of the data flow transferred via the 3GPP access link 608 and some other traffic of the same data flow (comprising the first subflow and the second subflow) transferred via the non-3GPP access link 610 based on the received access flow information (e.g., based on the data flow information) to perform access traffic splitting. In other embodiments, the core network 604 may instruct the UE 606 to move the data flow from the 3GPP access link 608 to the non-3GPP access link 610 or from the non-3GPP access link 610 to the 3GPP access link 608. In some embodiment, the signal provided at operation 5, contains rules for traffic switching and/or splitting, which instruct or control the UE 606 to change the priority of subflow (s) (e.g., by designating one of the subflows as a main subflow and the other subflow for use only under certain conditions) or removing one subflow.

At operation 6, the UE 606 sends MPTCP configuration information (e.g., change of subflow priority, removing a subflow, etc. ) to the application server 602 based on the instruction/rules signal received from the core network 604 at operation 5. For example, the UE 606 may send the MPTCP configuration information to the application server 602 to implement the particular access traffic configuration (e.g., access traffic steering, switching, and/or splitting) specified in the instruction signal received from the core network 604 in operation 5.

Figure 7 is a block diagram of an ATSSS policy information data structure 700, in accordance with some embodiments. The ATSSS policy information data structure 700 may be similar to parameter contents field of a unit carrying a network based IP flow mobility (NBIFOM) routing rules parameter as defined in 3GPP TS 24.161. For example, the ATSSS policy information data structure 700 may be divided into an arbitrary number of five octets sets that each include, respectively, various parameters. These parameters may be: a length of a routing rule (e.g., length of routing rule 1 702 at octet 1； length of routing rule n 704 at octet y+1) ； a routing rule identifier (e.g., routing rule identifier 1 706 at octet 2； routing rule identifier n 708 at octet y+2) ； a combination of routing access information, spare fields, and operation codes (e.g., routing access 1 710, 0 spares 712, and operation code 1 720 at octet 3；

routing access n

722, 0 spares 724, operation code n 730 at octet y+3) ； routing rule priority information (e.g., routing rule priority 1 732 at octet 4； routing rule priority n 734 at octet y+4) ； and routing filter information (e.g., routing filter 1 736； routing filter n 738 at octet y+5) . The values “x” , “y” , and “z” are used to designate arbitrary values for octets.

The routing rules (in octets 1 to z) may contain a list of routing rules, each one in a separate unit including a length of routing rule field, and the routing rule contents. The routing rule contents may include a routing rule identifier field, a routing access field, an operation code field, a routing rule priority field, and a routing filter field. The length of routing rule field (in octet 1 and octet y+1) of a unit contains the binary coded representation of the length of the routing rule contents of the unit. Bit 8 of the length of routing filter field contains the most significant bit. The routing rule identifier (in octet 2 and y+2) may uniquely identify the routing rule within one multi-access PDN connection. The routing rule identifier may be allocated by the entity creating the routing rule (e.g., by the UE in a UE-initiated NBIFOM mode and by the PDN gateway (GW) in a network-initiated NBIFOM mode) .

The operation code may be represented in accordance with Table 1, below:

Bit 3	Bit 2	Bit 1
0	0	0	Spare
0	0	1	Create routing rule
0	1	0	Delete routing rule
0	1	1	Replace existing routing rule

1

0

Reserved (the values from “100” to “111 are reserved”

Table 1: Operation codes (bits 1-3 in octet 3 and y+3)

The routing access may be represented in accordance with Table 2, below:

Bit 8	Bit 7
0	1	3GPP access link
1	0	Non-3GPP access link

Table 2: routing access (bits 8-7 in octet 3 and y+3)

The routing rule priority (in octet 4 and y+4) indicates the order of the routing rule application when the IP packet matches more than one routing filter. The lower value indicates higher priority.

Figure 8 illustrates a method of a UE 802 providing active flow information to a core network 804, in accordance with some embodiments of the invention. Operations 1-3B, 5 and 6 are same as discussed above in connection to Figure 6.

Returning to Figure 8, at operation 4, the UE 802 provides active flow information to the core network 804. The active flow information may be generated by an ATSSS client function (discussed above in connection with Figure 4) at the UE 802 based on the data flow (e.g., the first subflow of operation 3A and the second subflow of operation 3B) . The active flow information may be a type of connection information. Also, as discussed above, the active flow information may include data flow information, or parameters, such as a data rate, error rate, or other parameters to determine how well communication under a particular subflow (and/or under a 3GPP access link 806 or a non-3GPP access link 808) is performing.

Figure 9 illustrates a method of either and/or both a UE 902 and an application server 904 providing active flow information to a core network 906, in accordance with some embodiments of the invention. For Figure 9, operations 1-3B, are same as discussed above in connection to Figure 6.

Returning to Figure 9, at operation 4A and operation 4B, the UE 902 and/or the application server 904 may provide active flow information to the core network 906. This active flow information may be generated locally at the UE 902 and/or locally at the application server 904. The active flow information may be a type of connection information. As discussed above, the active flow information may include data flow information, or parameters, such as a data rate, error rate, or other parameters to determine how well communication under a particular subflow (and/or under a 3GPP access link 908 or a non-3GPP access link 910) is performing. For example, in operation 4A, the UE 902 may provide active flow information to the core network 906. Also, in operation 4B, the application server 904 may provide active flow information to the core network 906. Although Figure 9 illustrates operation 4A before operation 4B,

operations

4A and 4B need not be in a particular order such that operation 4B may be executed before operation 4A or

operations

4A and 4B may be executed simultaneously. Also, in certain embodiments, only operation 4A is executed while operation 4B is not executed while in other embodiments operation 4B is executed while operation 4A is not executed.

Operations

4A and 4B are illustrated in dotted lines to indicate that they may both be executed or either may be executed.

At operation 5, the core network 906 may instruct the application server 904 to dynamically reconfigure its access traffic configuration. This instruction or rules signal may be a radio signal that encodes a request, rule, or instruction decodable by the UE 902 and/or the application server 904 to perform a particular access traffic configuration. For example, in certain embodiments, the core network 906 may instruct the application server 904 to have some traffic of the data flow transferred via the 3GPP access link 908 and some other traffic of the same data flow (comprising the first subflow and the second subflow) transferred via the non-3GPP access link 910 based on the received access flow information (e.g., based on the data flow information) to perform access traffic splitting. In other embodiments, the core network 906 may instruct the application server 904 to move the data flow from the 3GPP access link 908 to the non-3GPP access link 910 or from the non-3GPP access link 910 to the 3GPP access link 908. In some embodiment, the signal provided at operation 5, contains rules for traffic switching and/or splitting, which instruct or control the application server 904 to change the priority of subflow (s) (e.g., by designating one of the subflows as a main subflow and the other subflow for use only under certain conditions) or removing one subflow.

At operation 6, the application server 904 sends MPTCP configuration information (e.g., change of subflow priority, removing a subflow, etc. ) to the UE 902 based on the instruction/rules signal received from the core network 906 at operation 5. For example, the application server 904 may send the MPTCP configuration information to the UE 902 to implement the particular access traffic configuration (e.g., access traffic steering, switching, and/or splitting) specified in the instruction signal received from the core network 906 in operation 5.

While various embodiments of the invention have been described above, they have been presented by way of example only, and not by way of limitation. Likewise, the various diagrams may depict an example architectural or configuration, which are provided to enable persons of ordinary skill in the art to understand exemplary features and functions of the invention. Such persons would understand, however, that the invention is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, as would be understood by persons of ordinary skill in the art, one or more features of one embodiment can be combined with one or more features of another embodiment described herein. Thus, the breadth and scope of the present disclosure is not limited to the above-described exemplary embodiments.

Additionally, any reference to an element herein using a designation such as "first, " "second, " and so forth does not generally limit the quantity or order of those elements. Rather, these designations are used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements can be present, or that the first element must precede the second element in some manner.

Additionally, a person having ordinary skill in the art would understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits and symbols, for example, which may be referenced in the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

A person of ordinary skill in the art would further appreciate that any of the various illustrative logical blocks, modules, processors, means, circuits, methods and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two) , firmware, software, or any combination of these techniques. To illustrate this interchangeability of hardware, firmware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware or software, or a combination of these technique, depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in various ways for each particular application, but such implementation would not cause a departure from the scope of the present disclosure.

Furthermore, a person of ordinary skill in the art would understand that various illustrative logical blocks, modules, devices, components and circuits described herein can be implemented within or performed by an integrated circuit (IC) that can include a general purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or other programmable logic device, or any combination of these implementations. The logical blocks, modules, and circuits can further include antennas and/or transceivers to communicate with various components within the network or within the device. A general purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration to perform the functions described herein.

If implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium. Thus, the steps of a method or algorithm disclosed herein can be implemented by executing software stored on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that can transfer a computer program or code from one place to another. A storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can store desired program code in the form of instructions or data structures and that can be accessed by a computer.

In this document, the terms "module" or “unit” as used herein, refer to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purpose of discussion, the various modules or units are described as discrete modules or units； however, as would be apparent to one of ordinary skill in the art, two or more modules or units may be combined to form a single module or unit that performs the associated functions according embodiments of the invention.

Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention. It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processing logic elements, or controllers, may be performed by the same processing logic element, or controller. Hence, references to specific functional units are only references to a suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.

Various modifications to the implementations described in this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations without departing from the scope of this disclosure. Thus, the disclosure is not intended to be limited to the implementations shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as recited in the claims below.

Claims

A method, comprising:

establishing a connection between a user equipment and a core network；

establishing a first subflow and a second subflow to transfer a data flow through a first type communication link and a second type communication link, respectively；

providing connection information concerning the first subflow and the second subflow to the core network； and

based on the connection information, adjusting the first and second subflows to provide an adjusted data flow.
The method of claim 1, wherein the adjusting the first and second subflows comprises access traffic steering wherein either the first subflow or the second subflow is used for a new data flow, wherein the adjusted data flow comprises the new data flow.
The method of claim 1, wherein the adjusting the first and second subflows comprises access traffic switching wherein all of the data flow is switched from the first subflow to the second subflow, or from the second subflow to the first subflow, to provide the adjusted data flow.
The method of claim 1, wherein the adjusting the first and second subflows comprises access traffic splitting wherein the data flow is split between the first and second subflows to provide the adjusted data flow.
The method of claim 1, wherein the connection information is provided by the user equipment to the core network.
The method of claim 1, wherein the connection information is provided by an application server (AS) to the core network.
The method of claim 1, wherein the connection information comprises at least one of: 5-tuple Multi-path Transfer Control Protocol (MPTCP) connection information； a unique identifier of a MPTCP connection between the user equipment and an application server； and a MPTCP connection application identification.
The method of claim 1, wherein the connection is established in accordance with a predefined Access Traffic Steering, Switching, and Splitting (ATSSS) policy.
The method of claim 1, wherein the data flow is between the user equipment and an application server (AS) .
The method of claim 1, wherein the first and second subflows are adjusted based on an instruction signal received from the core network, wherein the instruction signal is generated based on the connection information.
A method comprising:

establishing a connection between a user equipment and a core network；

receiving connection information concerning a first subflow and a second subflow, wherein the first subflow and the second subflow transfer an data flow through a first type communication link and a second type communication link, respectively；

generating an instruction signal for adjustment of the first and second subflows to provide an adjusted data flow； and

sending the instruction signal.
The method of claim 11, wherein the adjustment of the first and second subflows comprises access traffic steering wherein either the first subflow or the second subflow is used for a new data flow, wherein the adjusted data flow comprises the new data flow.
The method of claim 11, wherein the adjustment of the first and second subflows comprises access traffic switching wherein all of the data flow is switched from the first subflow to the second subflow, or from the second subflow to the first subflow, to provide the adjusted data flow.
The method of claim 11, wherein the adjustment of the first and second subflows comprises access traffic splitting wherein the data flow is split between the first and second subflows to provide the adjusted data flow.
The method of claim 11, further comprising sending the instruction signal to the user equipment.
The method of claim 11, further comprising sending the instruction signal to an application server (AS) .
The method of claim 11, wherein the connection information is received from the user equipment.
The method of claim 11, wherein the connection information is received from an application server (AS) .
The method of claim 11, wherein the connection information comprises at least one of: 5-tuple Multi-path Transfer Control Protocol (MPTCP) connection information； a unique identifier of a MPTCP connection between the user equipment and an application server； and a MPTCP connection application identification.
The method of claim 11, wherein the connection is established in accordance with a predefined Access Traffic Steering, Switching, and Splitting (ATSSS) policy.
An apparatus, comprising:

a transceiver； and

at least one processor configured to:

establish, using the transceiver, a connection between a user equipment and a core network；

establish, using the transceiver, a first subflow and a second subflow to transfer a data flow through a first type communication link and a second type communication link, respectively；

provide, using the transceiver, connection information concerning the first subflow and the second subflow to the core network； and

based on the connection information, adjust, using the transceiver, the first and second subflows to provide an adjusted data flow.
The apparatus of claim 21, wherein the adjusting the first and second subflows comprises access traffic steering wherein either the first subflow or the second subflow is used for a new data flow, wherein the adjusted data flow comprises the new data flow.
The apparatus of claim 21, wherein the adjusting the first and second subflows comprises access traffic switching wherein all of the data flow is switched from the first subflow to the second subflow, or from the second subflow to the first subflow, to provide the adjusted data flow.
The apparatus of claim 21, wherein the adjusting the first and second subflows comprises access traffic splitting wherein the data flow is split between the first and second subflows to provide the adjusted data flow.
The apparatus of claim 21, wherein the at least one processor is configured to provide, using the transceiver, the connection information to the core network.
The apparatus of claim 21, wherein the connection information comprises at least one of: 5-tuple Multi-path Transfer Control Protocol (MPTCP) connection information； a unique identifier of a MPTCP connection between the user equipment and an application server； and a MPTCP connection application identification.
The apparatus of claim 21, wherein the connection is established in accordance with a predetermined Access Traffic Steering, Switching, and Splitting (ATSSS) policy.
The apparatus of claim 21, wherein the data flow is between the user equipment and an application server (AS) .
A system, comprising:

at least one transceiver, the at least one transceiver comprising:

at least one transmitter, and

at least one receiver； and

at least one processor configured to:

establish, using the at least one transceiver, a connection between a user equipment and a core network；

receive, using the at least one receiver, connection information concerning a first subflow and a second subflow, wherein the first subflow and the second subflow transfer a data flow through a first type communication link and a second type communication link, respectively；

generate an instruction signal for adjustment of the first and second subflows to provide an adjusted data flow； and

send, using the at least one transmitter, the instruction signal.
The system of claim 29, wherein the adjustment of the first and second subflows comprises access traffic steering wherein either the first subflow or the second subflow is used for a new data flow, wherein the adjusted data flow comprises the new data flow.
The system of claim 29, wherein the adjustment of the first and second subflows comprises access traffic switching wherein all of the data flow is switched from the first subflow to the second subflow, or from the second subflow to the first subflow, to provide the adjusted data flow.
The system of claim 29, wherein the adjustment of the first and second subflows comprises access traffic splitting wherein the data flow is split between the first and second subflows to provide the adjusted data flow.
The system of claim 29, wherein the at least one transmitter is configured to send the instruction signal to the user equipment.
The system of claim 29, wherein the at least one transmitter is configured to send the instruction signal to an application server (AS) .
The system of claim 29, wherein the at least one receiver is configured to receive the connection information from the user equipment.
The system of claim 29, wherein the at least one receiver is configured to receive the connection information from an application server (AS) .