WO2016003176A1

WO2016003176A1 - Method and apparatus for determining traffic off-loading

Info

Publication number: WO2016003176A1
Application number: PCT/KR2015/006737
Authority: WO
Inventors: 정상수; 조성연
Original assignee: 삼성전자 주식회사
Priority date: 2014-06-30
Filing date: 2015-06-30
Publication date: 2016-01-07

Abstract

The present invention relates to a communication technology combining 5G communication system, which supports a higher transmission rate beyond the 4G system, with IoT technology, and a system therefor. The present invention, on the basis of 5G communication and IoT-related technologies, can be applied to intelligent services (for example, smart home, smart building, smart city, smart or connected car, healthcare, digital education, retail businesses, services related to security and safety, and the like). A method for a terminal to transceive a signal in a mobile communication system according to one embodiment of the present specification comprises the steps of: transmitting a connection request message comprising request information for controlling IP flow by means of a packet data network gateway (PGW); receiving, from the PGW, a connection response message comprising acceptance information for controlling the IP flow; and controlling the IP flow associated with the connection on the basis of the acceptance information for controlling the IP flow. According to one embodiment of the present specification, traffic can be effectively off-loaded for a terminal capable of connecting to both 3GPP and non-3GPP networks by clarifying the principal agent capable of making a decision regarding traffic off-loading or of starting the traffic off-loading process, or by enabling each traffic off-loading process to be distinguished when two or more traffic off-loading processes occur in parallel.

Description

Method and apparatus for traffic offloading determination

An embodiment of the present specification provides a service for effectively transmitting and receiving data by simultaneously using a 3GPP system such as LTE and a non-3GPP system such as a wireless LAN in a network in which a 3GPP system and a non-3GPP system coexist. to be. More specifically, when a user terminal can simultaneously use a 3GPP system and a non-3GPP system, it is a technique for performing traffic offloading, and select the determining agent of the traffic offloading.

In order to meet the increasing demand for wireless data traffic since the commercialization of 4G communication systems, efforts are being made to develop improved 5G communication systems or pre-5G communication systems. For this reason, a 5G communication system or a pre-5G communication system is called a system after a 4G network (Beyond 4G Network) or a system after an LTE system (Post LTE). In order to achieve high data rates, 5G communication systems are being considered for implementation in the ultra-high frequency (mmWave) band (eg, such as the 60 Gigabit (60 GHz) band). In order to mitigate the path loss of radio waves in the ultra-high frequency band and increase the propagation distance of radio waves, beamforming, massive array multiple input / output (FD-MIMO), and FD-MIMO are used in 5G communication systems. Array antenna, analog beam-forming, and large scale antenna techniques are discussed. In addition, in order to improve the network of the system, 5G communication systems have advanced small cells, advanced small cells, cloud radio access network (cloud RAN), ultra-dense network (ultra-dense network) , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation The development of such technology is being done. In addition, in 5G systems, Hybrid FSK and QAM Modulation (FQAM) and Slide Window Superposition Coding (SWSC), Advanced Coding Modulation (ACM), and FBMC (Filter Bank Multi Carrier) and NOMA are advanced access technologies. (non orthogonal multiple access), and sparse code multiple access (SCMA) are being developed.

Meanwhile, the Internet is evolving from a human-centered connection network in which humans create and consume information, and an Internet of Things (IoT) network that exchanges and processes information between distributed components such as things. The Internet of Everything (IoE) technology, which combines big data processing technology through connection with cloud servers and the like, is emerging. In order to implement the IoT, technical elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology are required, and recently, a sensor network for connection between things, a machine to machine , M2M), Machine Type Communication (MTC), etc. are being studied. In an IoT environment, intelligent Internet technology (IT) services can be provided that collect and analyze data generated from connected objects to create new value in human life. IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliances, advanced medical services, etc. through convergence and complex of existing information technology (IT) technology and various industries. It can be applied to.

Accordingly, various attempts have been made to apply the 5G communication system to the IoT network. For example, technologies such as sensor network, machine to machine (M2M), machine type communication (MTC), and the like, are implemented by techniques such as beamforming, MIMO, and array antennas. It is. Application of cloud radio access network (cloud RAN) as the big data processing technology described above may be an example of convergence of 5G technology and IoT technology.

In general, mobile communication systems have been developed to provide voice services while guaranteeing user activity. However, mobile communication systems are gradually expanding not only voice but also data services, and now they have developed to the extent that they can provide high-speed data services. However, a shortage of resources is occurring in the mobile communication system in which a service is currently provided, and a more advanced mobile communication system is required because users require higher speed services.

In response to these demands, one of the systems being developed as a next-generation mobile communication system, a specification work for Long Term Evolution (LTE) is underway in the 3GPP (The 3rd Generation Partnership Project). LTE is a technology that implements high-speed packet-based communication with a transmission rate of up to 100 Mbps. To this end, various methods are discussed. For example, the network structure can be simplified to reduce the number of nodes located on the communication path, or the wireless protocols can be as close to the wireless channel as possible.

In such a mobile communication system, the terminal may simultaneously use a plurality of heterogeneous networks. In particular, the UE may simultaneously use a 3GPP access network such as GERAN / UTRAN / E-UTRAN and a non-3GPP access network such as a wireless local area network (WLAN). For example, the user terminal may transmit and receive data by connecting to the E-UTRAN while simultaneously connecting to the WLAN for other traffic. The traffic offloading decision may be made in consideration of the state of the user terminal, the state of the WLAN, and the operator network state.

When a user terminal uses a service connected to a specific packet data network (PDN) through a non-3GPP system, the user terminal connects to a packet data network gateway (P-GW). (Connection) needs to be created. In order to improve service provider network configuration and service freedom for users, the network may create one or more PDN connections for PDNs having the same access point name (APN) even when a user terminal accesses using a WLAN. You must allow it. Alternatively, a method of supporting a user terminal to simultaneously transmit and receive traffic through a 3GPP system and a non-3GPP system using one IP address may be allowed. At this time, an access network for transmitting / receiving specific traffic, that is, authority to determine whether to offload traffic may be given to both the user terminal and the operator network. At this time, if the user terminal starts the process for traffic offloading, if the node of the operator network also starts the process for traffic offloading, the two processes may collide with each other, increase the possibility of error or inefficiency in operation. What is possible is a method and apparatus that can solve this problem.

Signal transmitting and receiving method in a terminal of a mobile communication system according to an embodiment of the present disclosure for solving the above problems is a step of transmitting a connection request message including request information for IP flow control to a packet data network gateway (PGW) ; Receiving a connection response message including authorization information for IP flow control from the PGW; And controlling the IP flow related to the connection based on the admission information for the IP flow control.

Signal transmission and reception method in a packet data network gateway (PGW) of a mobile communication system according to another embodiment of the present disclosure comprises the steps of receiving a connection request message including request information for IP flow control from the terminal; Transmitting a connection response message including authorization information for IP flow control to the terminal; And controlling the IP flow related to the connection based on the admission information for the IP flow control.

Terminal of a mobile communication system according to another embodiment of the present disclosure includes a transceiver for transmitting and receiving a signal; And controlling the transceiver, transmitting a connection request message including request information for IP flow control to a packet data network gateway (PGW), and receiving a connection response message including approval information for IP flow control from the PGW. And a controller for controlling the IP flow related to the connection based on the admission information for the IP flow control.

Packet data network gateway (PGW) of a mobile communication system according to another embodiment of the present disclosure includes a transceiver for transmitting and receiving a signal; And controlling the transceiver, receiving a connection request message including request information for IP flow control from a terminal, transmitting a connection response message including authorization information for IP flow control to the terminal, and controlling the IP flow. It includes a control unit for controlling the IP flow associated with the connection based on the approval information for.

According to an embodiment of the present disclosure, it is possible to clarify the subject that can start the traffic offloading decision or traffic offloading process for the terminal that can access the 3GPP network and non 3GPP network together, or two or more traffic offloading process When it occurs in parallel, each traffic offloading process can be distinguished so that traffic offloading can be efficiently performed.

FIG. 1 is a diagram schematically illustrating a situation in which data is transmitted and received by simultaneously using a 3GPP access network and a non-3GPP access network according to an embodiment of the present disclosure.

FIG. 2 is a diagram illustrating an example of a block diagram of a trusted WLAN access network (TWAN) according to one embodiment of the present specification.

3 is a diagram briefly explaining a situation that may occur in the process of determining traffic offloading.

4 illustrates operations of a user terminal and a provider network node according to an exemplary embodiment of the present specification.

5 is a diagram illustrating an operation for determining an ICM of a user terminal and a network.

6 is a diagram illustrating operations of a user terminal and a network for determining an IFOM operation mode.

FIG. 7 illustrates an operation in which ANDSF is used to determine whether an initial ICM or NW (Network) -initiated IP flow mobility request is requested by a user terminal.

8 is a diagram illustrating an operation of exchanging information on IP flow mobility using a Protocol Configuration Option (PCO).

9 illustrates an operation for changing a node capable of initiating IP flow mobility according to an embodiment.

10 illustrates an operation for changing a node capable of initiating IP flow mobility according to another embodiment.

11 is a diagram illustrating a terminal according to an embodiment of the present disclosure.

12 is a diagram illustrating a core network entity according to an embodiment of the present specification.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

In describing the embodiments, descriptions of technical contents which are well known in the technical field to which the present invention belongs and are not directly related to the present invention will be omitted. This is to more clearly communicate without obscure the subject matter of the present invention by omitting unnecessary description.

For the same reason, in the accompanying drawings, some components are exaggerated, omitted or schematically illustrated. In addition, the size of each component does not fully reflect the actual size. The same or corresponding components in each drawing are given the same reference numerals.

Advantages and features of the present invention, and methods for achieving them will be apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various forms, and only the embodiments of the present invention make the disclosure of the present invention complete and the general knowledge in the technical field to which the present invention belongs. It is provided to fully convey the scope of the invention to those skilled in the art, and the present invention is defined only by the scope of the claims. Like reference numerals refer to like elements throughout.

At this point, it will be understood that each block of the flowchart illustrations and combinations of flowchart illustrations may be performed by computer program instructions. Since these computer program instructions may be mounted on a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, those instructions executed through the processor of the computer or other programmable data processing equipment may be described in flow chart block (s). It creates a means to perform the functions. These computer program instructions may be stored in a computer usable or computer readable memory that can be directed to a computer or other programmable data processing equipment to implement functionality in a particular manner, and thus the computer usable or computer readable memory. It is also possible for the instructions stored in to produce an article of manufacture containing instruction means for performing the functions described in the flowchart block (s). Computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operating steps may be performed on the computer or other programmable data processing equipment to create a computer-implemented process to create a computer or other programmable data. Instructions for performing the processing equipment may also provide steps for performing the functions described in the flowchart block (s).

In addition, each block may represent a portion of a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of order. For example, the two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the corresponding function.

In this case, the term '~ part' used in the present embodiment refers to software or a hardware component such as an FPGA or an ASIC, and '~ part' performs certain roles. However, '~' is not meant to be limited to software or hardware. '~ Portion' may be configured to be in an addressable storage medium or may be configured to play one or more processors. Thus, as an example, '~' means components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, procedures, and the like. Subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided within the components and the 'parts' may be combined into a smaller number of components and the 'parts' or further separated into additional components and the 'parts'. In addition, the components and '~' may be implemented to play one or more CPUs in the device or secure multimedia card.

In addition, in the following description of embodiments of the present specification, the basic Third Generation Partnership Project (3GPP) LTE system and a non-3GPP access network are referred to as a wireless local area network (WLAN). However, the main subject matter of the embodiments of the present specification is to be modified in a slight variation without departing from the scope of the embodiments of the present disclosure to other communication / computer systems having similar technical background and system form. Applicable, it will be possible to the judgment of those skilled in the art of the embodiments of the present disclosure.

For example, the object of application of the present invention may be a 1x / CDMA2000 system or a WiMAX system instead of a WLAN.

Referring to FIG. 1, although

only WLANs

120 and 130 are shown as non-3GPP access networks, as mentioned above, non-3GPP access networks are not only WLANs but also other non-3GPP standard access networks, e.g., 1x / CDMA2000 /. It may include an HRPD access network or a WiMAX network.

The non-3GPP access network can be broadly divided into a trusted non-3GPP access network 120 and an untrusted non-3GPP access network 130. This division may be determined by whether the operator can trust the non-3GPP access network connected to the provider network. If the non-3GPP access network is untrusted (Untrusted non-3GPP access network 130), the non-3GPP access network is a 3GPP provider network, e.g. P-GW via evolved Packet Data Gateway (ePDG) 140 And may be connected to 170. In an embodiment, the operator may include an operator operating a 3GPP access network, and the non-3GPP access network may be a service provider contracted with a 3GPP operator.

Alternatively, reliable non-3GPP access network 120 may be directly connected to P-GW 170 without ePDG. As such, the reliable non-3GPP access network 120 may be directly connected to an evolved packet core (EPC).

In FIG. 1, the

non-3GPP access network

120 and 130 is represented as one device for convenience of description, but the non-3GPP access network may be a network including a plurality of access points. In particular, when configuring a reliable non-3GPP access network with a WLAN, this is referred to as a Trusted WLAN Access Network (TWAN) 120, which may include one or more WiFi access points and a Trusted WLAN Access Gateway (TWAG).

That is, the WiFi access point is connected to the 3GPP provider network through the TWAG, and the TWAG may be physically separated from the WiFi access point, or may be implemented through a logical module for each device.

On the other hand, as shown in Figure 1, the user terminal via the Trusted WLAN (120) or Untrusted WLAN (130) non-Seamless WLAN NSWO (transmitting and receiving traffic with the external PDN (for example, the Internet) directly without passing through the carrier core network offloading) techniques.

In the embodiment, the 3GPP mobile communication system, particularly the LTE system may include a next-generation base station (Evolved Node B, EUTRAN, ENB, Node B) 150 and S-GW (S-GW) 160, The UE 110 may access an external network through the ENB 150, the S-GW 160, and the P-GW (PDN Gateway) 170. The P-GW usually has a Policy and Charging Enforcement Function (PCEF). If the PCEF is implemented separately from the P-GW, in the embodiment of the present invention, the P-GW may be replaced with the PCEF.

The PCRF (Policy and Charging Rules Function) 180 is a device that controls a policy related to the quality of service (QoS) of the user, and the Policy and Charging Control (PCC) rule corresponding to the policy is the P-GW 170. And can be applied to.

The eNB 150 is a RAN (Radio Access Network) node, and may perform functions corresponding to a Radio Network Controller (RNC) of a UTRAN system and a Base Station Controller (BSC) of a GERAN system. The eNB 150 is connected to the UE 110 by a radio channel and plays a role similar to that of the existing RNC / BSC. In addition, the base station 150 may use several cells at the same time. Therefore, embodiments of the present disclosure may be applied to a 2G / 3G legacy network when the eNB (E-UTRAN) 150 is replaced with UTRAN or GERAN.

The S-GW 160 is a device for providing a data bearer, and creates or removes a data bearer context according to the control of a mobility management entity (MME). The function of the S-GW 160 may correspond to the function of a Serving GPRS Support Node (SGSN) in a 2G / 3G network.

In a wireless communication system such as LTE, a unit to which QoS is applicable is an EPS bearer. One EPS bearer is used to send IP Flows with the same QoS requirements. The EPS bearer may be assigned parameters related to QoS, and may include a QoS Class Identifier (QCI) and an Allocation and Retention Priority (ARP).

In an embodiment, the EPS bearer may correspond to a PDP context of the GPRS system. When the user terminal 110 accesses an Evolved Packet Core (EPC) through a 3GPP or non-3GPP access network, the user terminal 110 generates a PDN connection. The PDN connection may include one or more EPS bearers, and an IP address for each PDN connection. Can be assigned. Hereinafter, in describing an embodiment of the present invention, the term PDN connection or connection may be understood as a concept including a logical path through which a terminal may exchange data with a PDN through a core network based on an IP address. .

FIG. 2 is a diagram illustrating an example of a block diagram of a trusted WLAN access network (TWAN) according to one embodiment of the present specification. More specifically, FIG. 2 may be viewed as a type of Trusted non-3GPP access network described with reference to FIG. 1.

Referring to FIG. 2, a Trusted WLAN Access Network (TWAN) 210 is a WLAN Access Network 220 consisting of one or more WLANs, a Trusted WLAN AAA Proxy for interworking with AAA. 230, and a Trusted WLAN Access Gateway (TWAG) 240 connecting the WLAN Access Network 210 and the P-GW (not shown).

The interface between the TWAG 240 and the P-GW may be referred to as S2a, and a protocol such as GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP) may be used. The above structure is just a logical structure, and in fact, the physical configuration may be more free. Also, according to an embodiment, the WLAN Access Network 220 and the TWAG 240 may be implemented in the same physical entity in the communication system.

Hereinafter, the aforementioned problem, that is, when a user terminal can use a non-3GPP access network and a 3GPP access network at the same time, how to create or manage a connection and specific traffic to any access network according to the user subscription information or network status The method of informing and determining whether to transmit will be described with reference to embodiments. However, the present invention is not limited to these embodiments, and it is possible to carry out other modifications based on the technical idea of the present invention in addition to the embodiments disclosed herein to those skilled in the art. It is self-evident to.

In describing the embodiments of the present specification, for the sake of brevity, the network configuration will mainly include a case in which a TWAN is included as a non-3GPP access network, but a main point of the present invention utilizes a PDN through a non-3GPP access network. It can be applied to any situation. That is, if the carrier network configuration uses an Untrusted WLAN, in the embodiment of the present invention, the TWAN may be replaced with an ePDG, and the ePDG may be replaced by exchanging a message with a user terminal through an untrusted WLAN.

Meanwhile, in describing an embodiment of the present invention, the IP flow control information may include information for identifying an IP flow, which is a TFT (Traffic Flow Templates), a packet filter, an IP flow descriptor, and a service data (SDF). Flow) Template may refer to all information that can be used to detect a specific IP flow.

In the present specification, TWAN and WLAN may be used interchangeably for convenience of description. In addition, for convenience of description, the WLAN may refer to an entity in charge of control in the WLAN, for example, a WLAN access point (AP), a TWAG, or an ePDG. In addition, for the sake of brevity, the description will be made based on the case in which the entity communicating with the UE is TWAN, but the entity in which the actual UE communicates is based on the protocol of the message exchanged by the actual UE. Element (ie, at least one of WLAN access network, TWAG, TWAP). For example, the Beacon message may be sent by the WLAN access network in the TWAN. In addition, the access network query protocol (ANQP) method may be applied between the UE and the WLAN access network in the TWAN, or an ANQP server connected thereto, or the TWAG. In addition, a WLAN control layer message (WLCP-WLAN Control Protocol) may be exchanged between the UE and the TWAG.

If the non-3GPP access network is untrusted, the information exchanged between the user terminal and the ePDG may be included in an Internet Key Exchange (IKE) message, not a WLAN control layer message, and may be transmitted through the non-3GPP access network. . If the user terminal directly exchanges information with the WLAN access network, the EAP message may be used.

Also, in the present specification, information exchange between WLAN and PCRF is Gateway Control Session establishment, modification, and termination, and information exchange between PGW and PCRF is IP-CAN session establishment, modification. (Modification), Termination, but in practice this process is sent by the WLAN or PGW to the PCRF with the information described in the embodiment in a Credit Control Request (CCR) message, and the PCRF answers the Credit Control Answer. ) May include information included in an embodiment in a message and correspond to transmission to a WLAN or a PGW. If the PCRF does not receive the request, transmitting the information described in the embodiment of the present invention to the WLAN or the PGW may be performed by the PCRF including the information described in the embodiment in the RA (Re-Auth) Request message. The WLAN or the PGW receiving the received information may correspond to the PCRF including the information included in the embodiment in the RA (Re-Auth) Answer message. In addition, in applying the embodiments of the present invention, the diameter message is not limited to that described above, and may be used by changing to another similar request / response message, in which one entity is an embodiment of the present specification as another entity. The information described in the above may be delivered, and the operations described in the embodiments of the present specification may be performed based on the transmitted information.

Meanwhile, as mentioned above, embodiments of the present invention will be described based on a case where a user terminal is assigned and used with an IP address simultaneously through a non-3GPP access network and a 3GPP access network. The example can be applied to a case where a user terminal uses a different IP address assigned to a non-3GPP access network and a 3GPP access network. In this case, the user terminal and each network entity are limited to the case where the user terminal has a connection to the same PGW. The exchanged information should include information (such as an IP address, a connection identifier, or an identifier of a basic bearer included in the connection) to identify a connection that is the target of the operation.

Meanwhile, in describing the embodiments of the present disclosure, the SGW may be partially omitted during the message exchange process of each embodiment. If one network entity, especially the MME, exchanges a message with a PGW, this message may be exchanged with the PGW via the SGW. That is, the SGW may forward the control message received from the MME to the PGW, and forward the message received from the PGW to the MME.In this case, the information entered into the GTP message generated by the SGW and delivered to the next hop may be included. ) Can use what it received from the previous hop.

Meanwhile, in describing the embodiments of the present specification, the traffic offloading determination or the start of the traffic offloading process may include whether to select IP flow mobility, that is, select an access network to transmit specific traffic, or change from one access network to another. May be determined or start the process for doing so. In addition, in describing the embodiments of the present disclosure, the WLAN may correspond to one of AP, TWAG, ePDG, or both of them. More specifically, the WLAN may include one or more of an AP, a TWAG, or an ePDG, and may be logically or physically collocated together.

The following describes a problem situation that embodiments of the present specification are trying to solve.

3 is a diagram briefly explaining a situation that may occur in the process of determining traffic offloading. More specifically, FIG. 3 is a diagram schematically illustrating a problem situation that may occur when traffic offloading is determined in a terminal and a network.

In an embodiment, the user equipment (UE) 302 and the PGW 304 may transmit and receive signals, respectively, and in this embodiment, the user terminal 302 and the operator are authorized to make decisions about IP flow mobility. It can be assumed that it is given to one node (PGW) 304 of the network. In addition, it may be assumed that the user terminal 302 may simultaneously use a 3GPP access network and a non3GPP access network using one IP address.

In step I, the user terminal 302 transmits a specific IP flow (traffic for a video service in this example) to the WLAN, determines that it is transmitted to LTE according to a specific state and condition, and starts a process for IP flow mobility. do. At this time, in the embodiment, since the IP flow is the last or only IP flow of the PDN connection through the WLAN, moving the IP flow to LTE may include not using a PDN connection through the WLAN anymore.

On the other hand, in step 315, one node of the operator network (in the embodiment, PGW 304) performs WLAN transmission of a specific IP flow (traffic for SNS service in this example) that has been transmitted to LTE in consideration of the operator network state or the state of the user terminal. You decide to move to and begin the process for this. The operation of step 315 may be performed at a time similar to the operation of step 310, and each step may be performed within a time range that may affect each other irrespective of afterwards.

By the above conditions, the operation of the user terminal 302 and the operator network 304 may cause a different result than the original intention, or may cause an error situation. For example, if the process of step 310 started by the user terminal 302 is completed before the request message according to the process of step 315 initiated by the node 304 of the operator's network arrives at the user terminal 302, the user terminal ( 302 is instructed to transmit traffic from the node 304 of the operator's network to the PDN connection that has already been lost. On the other hand, if the request message according to the process started in step 315 arrives at the user terminal 302 before the process started in step 310 by the user terminal 302, the user terminal 302 is originally It was not possible to perform the intended action (i.e., disconnect the PDN over the WLAN).

In an embodiment of the present disclosure, in order to solve the above situation (s), the operation of the user terminal 302 and the operator network node 304 performed for one IP flow mobility is combined into one transaction. We propose a method of grouping and separating each process so that it does not affect each other.

Meanwhile, in order to minimize unnecessary ambiguity that may occur due to IP flow mobility operation, the user terminal and the operator network always perform a process related to IP flow mobility through a new access network through which IP flow is transmitted and received due to IP flow mobility operation. Can be. For example, when the user terminal determines to move the IP flow transmitted and received in LTE to the WLAN, the user terminal may transmit the IP flow mobility request message through the WLAN rather than LTE. As another example, if a node of an operator network decides to move an IP flow transmitted and received to a WLAN to LTE, a control message exchanged with a user terminal during the IP flow mobility process may be transmitted through the LTE network.

Referring to FIG. 4, at least one of the user terminal 402, the non 3GPP access network 404, the 3GPP network 406, or the PGW 408 may transmit / receive a signal with another entity / network.

In the figure, two procedure transactions (hereinafter referred to as PTs) 410 and 460 are included, and the two

PTs

410 and 460 may be performed in parallel with each other. For convenience of description, PT1 410 describes that the user terminal 402 initiates IP flow mobility, and PT2 460 describes that one node (PGW) 408 of the operator network initiates IP flow mobility. In an embodiment, in order to initiate IP flow mobility in each PT or each PT, each entity may determine different types of messages according to the entity receiving the message.

In addition, in the present embodiment, the user terminal 402 creates a PDN connection so that a 3GPP access network (LTE / E-UTRAN, etc.) 406 and a non-3GPP access network (WLAN, etc.) 404 are configured with one IP address. Assume that we can use together.

In PT1 410, the user terminal 402 may decide to move the IP flow transmitted from one access network to another access network.

In operation 415, the user terminal 402 may transmit a request message for IP flow mobility through the access network 404. If an embodiment uses a WLAN, the WLAN is a trusted WLAN, and the user terminal 402 uses multiple connection mode, the user terminal 402 may use a WLCP request message or an IP flow mobility request message. Can be. According to an embodiment, at least one of the messages includes a TFT or packet filter including an ID for identifying a connection, information for identifying an IP flow (information for distinguishing an IP flow, an IP address / port, etc.), and a type of a target access network. Information, etc.), or at least one of a TID (Transaction ID). In the present embodiment, the TID is an identifier for distinguishing a session management procedure transaction and is a value that can be assigned by the user terminal 402.

In step 420, the access network node 404 receiving the IP flow mobility request from the user terminal 402, a message for updating information on the IP flow to the PGW 408, a Bearer Modify Command or a Proxy Binding Update (PBU) message, May be sent to the PGW 408. The message may include one or more of an ID for identifying a connection, IP flow information, or a TID, and such information may be generated based on values received from the user terminal 402.

In step 425, the PGW 408 determines whether to apply IP flow mobility based on the received information, and if it is determined to apply, a message for updating IP flow information (i.e., an access network to which the IP flow will be transmitted and received), Update. A Bearer Request or Proxy Binding Ack (PBA) message may be transmitted to the access network node 404. At least one of the messages may include one or more of an ID for identifying a connection, IP flow information, or a TID. In addition, the IP flow information may be information modified / updated based on the information received from the user terminal 402, and the TID is determined based on a value received from the user terminal 402, and more specifically, the user terminal. It is characterized by using the value received from (402).

In operation 430, the access network 404 may transmit a message for updating the IP flow information of the user terminal 402 to the user terminal 402. In an embodiment, if the access network 404 is a WLAN and the WLAN is a trusted WLAN, the message may be at least one of a WLCP message or an Update Route Request message. The message may include one or more of an ID for identifying a connection, IP flow information, or a TID. In an embodiment, the IP flow information may be information modified / updated based on information requested by the user terminal 402. The user terminal 402 compares the TID of the message received from the operator's network in this step with the TID inserted into the message transmitted in the previous step 415, and if it matches, the operator's network due to the request sent by the user. We can see that we sent a message to perform this IP flow mobility operation.

In operation 435, the user terminal 402 may transmit a response message indicating acceptance of IP flow mobility to the access network 404. If the access network 404 is a WLAN and the WLAN is a trusted WLAN, the message may be at least one of a WLCP message, an Update Route Response, or an Accept message. In an embodiment, the message includes one or more of an ID and a TID for identifying a connection, wherein the TID is determined based on the TID received in step 430, and more specifically, the same value as the TID received in step 430. Can be used.

In operation 440, the access network 404 may transmit a response message for the operation requested by the PGW 408, if necessary. The response message may be an Update Bearer Response message, and the message may include one or more of an ID or a TID for identifying a connection. The PGW 408 compares the TID of the received message with the TID that it included in the message sent in step 425 above (ie, obtained from the request message of the user terminal) to determine which PT response message. Can be.

Meanwhile, in order for the PGW 408 to start IP flow mobility in one embodiment of the operator network, in step 465, the PGW 408 is configured to update the IP flow information of the user terminal 402 to the access network 406. The message may be transmitted. In an embodiment, the message may be an Update Bearer Request message. The message may include one or more of an ID for identifying a connection, IP flow information, and a TID. In addition, in an embodiment, the TID may be determined based on an unassigned value or a value generated by the PGW.

In operation 470, the access network 406 may transmit a message for updating the IP flow information of the user terminal 402 to the user terminal 402, and the message for updating the IP flow information may be transmitted or received by the IP flow. It may be a message for changing the network. In an embodiment, when the access network 406 is LTE, the message may be at least one of a NAS ESM or a Modify EPS Bearer Context Request message. The message may include an ID for identifying a connection or a representative EPS bearer of the connection, an IP flow information (a TFT or packet filter configured with information for identifying an IP flow, an IP address / port, etc.), or a type of a target access network. At least one of the information), or at least one or more of the TID (Transaction ID) may be included. In an embodiment, the TID delivered by the access network 406 to the user terminal 402 may be determined based on the value received from the PGW 408, and more specifically, the TID value received from the PGW 408 may be used as it is. have.

In operation 475, the user terminal 402 may transmit a response message indicating acceptance of IP flow mobility to the access network 406. If the access network is LTE, the message may be at least one of a NAS ESM message or a Modify EPS Bearer Context Accept message. The message may include one or more of an ID or a TID for identifying a connection or a representative EPS bearer of the connection. In an embodiment, if the TID of the message received in the previous step is unassigned, the user terminal 402 may assign one TID value to include in the message or include the unassigned as it is. If the message received in the previous step includes a TID other than unassigned, the user terminal may include the TID received in the previous step in the message.

In operation 480, the access network 406 may transmit a response message for the operation requested by the PGW 408. In an embodiment, the response message may be an Update Bearer Response message, and the message may include one or more of an ID or a TID for identifying a connection. In this case, the TID is determined based on the value included in the message received from the user terminal 402, and more specifically, the same value as the TID included in the message received from the user terminal 402 may be used.

The PGW 408 compares the TID of the received message with the TID (i.e., obtained from the request message of the user terminal) included in the message sent in step 465 above to determine which PT response message. Can be.

In an embodiment, as in

steps

445 and 450, the user terminal 402 and the PGW 408 may process IP Flow Mobility (IFOM) based on the TID.

Meanwhile, in the above embodiment, the PT1 410 sends an IP flow mobility request to the user terminal 402 through the WLAN 404, and the PT2 460 performs an IP flow mobility process through the LTE 406 by the operator network. For example, the embodiment relates to a method of distinguishing an IP flow mobility PT initiated by a user terminal from an IP flow mobility PT initiated by an operator network. In another example, the user terminal 402 may request an IP flow mobility request. If sent through the LTE (406) can also be applied correspondingly. That is, according to the drawing, a user terminal transmits an IP flow mobility request through a non-3GPP (WLAN) access network, and one node (PGW) of the network performs an IP flow mobility operation through a 3GPP (LTE) access network. The main gist of the present embodiment may be applied to a case in which the type of access network is changed from each other so that a user terminal transmits an IP flow mobility request through an LTE network and performs an IP flow mobility process through a WLAN network in the network.

In the above embodiment, when the SGW exists between the access network and the PGW, the operation of the SGW is omitted for convenience of description. This is because the message transmitted and received by the SGW may be the same as the message transmitted and received by the PGW.

From now on, according to an embodiment of the present specification, a method of determining a node which plays a role of starting an IP flow mobility process among a user terminal and a provider network node will be described. If only one node of the user terminal and the provider network node can determine whether to start the process for IP flow mobility, as described above, it is possible to prevent problems in managing IP flow or PDN connection.

In the following description of embodiments of the present invention, there are three modes for controlling IP flow mobility (IFOM Control Mode, hereinafter referred to as ICM).

UE only: Only user equipment can perform initiation for IP flow mobility.

-NW (Network) only: Only the nodes (for example, PGW) of the provider network can perform initiation for IP flow mobility.

NW and UE: Initiation of IP flow mobility can be performed by both UE and NW.

In the exemplary embodiment, the name of such a mode is exemplary and may be changed and used in terms understood by those skilled in the art.

5 is a diagram illustrating an operation for determining an ICM of a user terminal and a network. Referring to FIG. 5, in an embodiment, the user terminal 502, the WLAN / MME 504, and the PGW 506 may each transmit and receive signals with at least one of other entities.

In operation 510, the user terminal 502 may transmit a request message for creating a PDN connection to the WLAN / MME 504. If the access network is a WLAN and the WLAN is a trusted WLAN, the message may be a WLCP message. In addition, when the access network is E-UTRAN, the message may be a NAS ESM message. In another embodiment, the message may be a PDN connectivity request message, and the message may include at least one of an APN or an ICM requested by the user terminal.

In step 515, the WLAN network or the MME 504 may transmit a message, a Create Session Request, or a PBU message for creating a PDN connection to the PGW 506 according to a request of the user terminal 502. The message may include at least one of APN and ICM.

In operation 520, the PGW 506 may determine an ICM for the user terminal 502. At this time, the PGW 506 may consider the APN requested from the user terminal 502 and may determine whether to allow the ICM requested by the user terminal 502 or whether a change to another ICM is necessary. In addition, during this process, the PGW 506 may consider local configuration and user subscription information, and may use information received from a separate network node, for example, a PCRF. Alternatively, the PGW 506 may deliver the ICM requested by the user terminal 502 to the PCRF, and notify the user terminal 502 of the ICM determined by the PCRF again.

At step 525, the PGW 506 may send a response message to the WLAN / MME 504 in response to the request. In an embodiment, this message may be a Create Session Response or PBA message. The message may include the ICM for the PDN connection of the user terminal 502 finally determined.

In step 530, the MME or WLAN 504 may transmit a response message to the user terminal 502 in response to the PDN connection creation request. If the access network is a WLAN and the WLAN is a trusted WLAN, the message may be a WLCP message. In addition, when the access network is E-UTRAN, the message may be a NAS ESM message. The message may be a PDN connectivity accept message (when WLCP) or an activate default bearer request (when NAS ESM), and the message includes an ICM to be applied by the user terminal 502. The ICM to be applied in an embodiment may include at least one of an ICM value or ICM related information to be applied. The ICM-related information may include at least one of PDN-related information to which ICM is applied or conditions to which ICM is to be applied.

In operation 535, the user terminal 502 sets a mode of network-based IP flow mobility (NB-IFOM) operation, that is, at least one of UE-only, NW-only, or NW and UE according to the received message. Then, it can be applied to the IFOM operation. In addition, in the present embodiment, the operation mode may be limited to the target PDN connection.

Referring to FIG. 6, in an embodiment, the user terminal 602, the MME 604, and the home subscriber server (HSS) 606 may each transmit and receive signals with at least one of other entities.

In operation 610, the user terminal 602 may perform an attachment (attach or TAU) to the EPC through the E-UTRAN. The user terminal 602 transmits an attach request or TA update request message to the MME 604, which requests NW-initiated IP flow mobility application to the ICM or the user terminal 602 of the user terminal 602. One or more of the information may be included.

In step 615, the MME 604 transmits a message requesting the location registration of the user terminal 602 to the HSS 606. In an embodiment, the message may be an Update Location message.

In operation 620, the HSS 606 may transmit a response message to the request of the MME 604. The response message may be an Update Location Ack message, and the message may include at least one of information indicating whether to apply ICM or NW-initiated IP flow mobility to be applied to the user terminal as one of the subscription information of the user terminal 602. have.

In operation 625, the MME 604 may use the user terminal 602 based on at least one of information requested by the user terminal 602 in operation 610, information received from the HSS 606 in operation 620, or a local configuration of the MME 604. It can decide whether to support ICM or NW-iniaited IP flow mobility.

In step 630, the MME 604 may perform NW-initiated IP flow mobility for the ICM or the user terminal that the user terminal 602 should apply to the registration accept message, attach accept or TA update accept message sent to the user terminal 602. At least one of information indicating whether it is supported may be included and transmitted. .

In step 635, the user terminal 602 according to the message received from the MME 604, whether its operation mode is UE-only, NW-only, NW and UE or whether NW-initiated IP flow mobility is supported. Can be applied.

In the above embodiment, NW-initiated IP flow mobility is supported, so that a node of the operator network, for example, PGW or PCRF, may determine IP flow mobility and start a procedure for the UE instead of the user terminal 602. Means. Meanwhile, in the present embodiment, the information (ICM or NW-initiated IP flow mobility) may be set for each APN and transmitted to the user terminal. In this case, the user terminal should operate according to the setting of the APN that is currently the target. In addition, the information may be set differently for each APN.

FIG. 7 illustrates an operation in which an access network discovery and selection function (ANDSF) is used to determine whether to request an initial ICM or NW-initiated IP flow mobility of a user terminal.

Referring to FIG. 7, the ANDSF 702 or the user terminal 702 may transmit and receive signals with each other.

In operation 710, the ANDSF 702 may transmit policy information to the user terminal 704. In an embodiment, the policy information includes at least one of information for access network selection / search or information for traffic routing determination. In addition, the information provided to the user terminal 704 may be referred to as ANDSF policy or ANDSF rule. In addition, the information may include one or more of ICM applicable to the user terminal 704 and information indicating whether to use NW-initiated IP flow mobility. In addition, in the present embodiment, the information may be set for each specific APN, it may be set to different for each specific APN. The information may be included in a WLAN selection policy, an inter-system mobility policy, an inter-system routing policy, an inter-APN routing policy, or may be included in an IP flow mobility policy.

In step 715, the user terminal 704 stores at least one of information received from the ANDSF 704, ICM, or whether to use NW-initiated IP flow mobility, and based on this, the user terminal 704 is associated with the start of another embodiment of the present invention. The initial value of the information can be determined. For example, if the ICM is set to UE_only in the ANDSF policy received by the user terminal 704 from a specific PLMN, the ICM of the request message sent to the operator network of the PLMN is set to UE_only.

Meanwhile, in the above embodiment, the ANDSF 702 may be an open mobile alliance-device management (OMA-DM) server, and the ANDSF policy may be another kind of information having a form of a management object (MO) of the OMA-DM.

Referring to FIG. 8, in an embodiment, at least one of the user terminal 802, the MME / WLAN 804, the PGW 806, or the PCRF 808 may transmit and receive signals with at least one of other entities.

In operation 810, the user terminal 802 may transmit a request message for creating a PDN connection to the MME / WLAN 804. In an embodiment, if the access network is a WLAN and the WLAN is a trusted WLAN, the message may be a WLCP message. In addition, when the access network is E-UTRAN, the message may be a NAS ESM message. The message may be a PDN connectivity request message, and the message may include at least one of APN, ICM information, or NW-initiated IP flow mobility information requested by the user terminal. In particular, the ICM information and the NW-initiated IP flow mobility request may be included as one of the protocol configuration options (PCOs) included in the message. In addition, in the present embodiment, the information may be applied to the target PDN connection limited.

In step 815, the WLAN network or the MME 804 may transmit a message, a Create Session Request message, or a PBU message to the PGW 806 to create a PDN connection according to a request of the user terminal 802. The message may include at least one of information requesting APN, ICM request, or NW-initiated IP flow mobility. In particular, when the PCO is included in the message received from the user terminal 802, the WLAN network or the MME 804 includes the received PCO in the message and delivers it to the PGW 806.

The PGW 806 receives the PCO transmitted from the user terminal 802 and receives ICM information included in the PCO or request information for NW-initiated IP flow mobility.

In step 825, the PGW 806 determines whether to support ICM or NW-initiated IP flow mobility to be applied to the user terminal 802 according to the request, wherein the PGW 806 is requested from the user terminal 802. The APN may be considered, and during this process, the PGW 806 may consider local configuration and user subscription information, and may use information received from a separate network node, for example, the PCRF 808. Alternatively, the PGW may deliver the ICM requested by the user terminal to the PCRF as in step 820, and notify the user terminal of the ICM determined by the PCRF again. In an embodiment, the operation of step 820 may be selectively performed.

In operation 830, the PGW 806 may transmit a response message to the request to the MME / WLAN 804. In an embodiment, the response message may be at least one of a Create Session Response or a PBA message. In addition, the response message includes whether the ICM or NW-initiated IP flow mobility support for the PDN connection of the determined user terminal 802.

In step 835, the MME or WLAN 804 may send a response message to the user terminal 802 in response to the PDN connection creation request. In an embodiment, if the access network is a WLAN and the WLAN is a trusted WLAN, the message may be a WLCP message, and if the access network is an E-UTRAN, the message may be a NAS ESM message. The message may be at least one of a PDN connectivity accept message (when WLCP) or an activate default bearer request (when NAS ESM), and ICM or NW-initiated IP flow mobility to be applied by the user terminal 802 to the message. Support is included.

In step 840, the user terminal 802 sets the mode of NB-IFOM operation, that is, one of UE-only, NW-only, and NW and UE, if ICM is included in the received message. Applicable to the operation. Alternatively, if the received message includes whether NW-initiated IP flow mobility is supported, the user terminal 802 may determine whether NW-initiated IP flow mobility is supported accordingly.

Referring to FIG. 9, in an embodiment, the user terminal 902, the MME / WLAN 904, and the PGW 906 may each transmit and receive signals with at least one of other entities.

In step 910, the user terminal 902 is registered in the provider network, and a node capable of initiating IP flow mobility is determined. The method of determining a node capable of IP flow initiation in an embodiment may include an embodiment disclosed herein or a method other than the embodiment.

In step 915, the node of the operator's network, eg, the PGW 906, decides to change the ICM for the user terminal 902. This may be determined in consideration of at least one of a local configuration of the PGW 906, a network state, or information received from the PCRF. In addition, the ICM may be information set for each PDN connection.

At step 915, the PGW 906 may send a message to the MME or WLAN 904 to update the ICM. In an embodiment, the message used to update the ICM may be an Update Bearer Request message, and the message may include information related to the ICM to be applied by the user terminal 902.

In step 925, the MME or WLAN 904 may send a message for notifying the user terminal 902 of the changed ICM. The message used to inform the changed ICM may be a message using the WLCP protocol, an update connection request when the node transmitting the message is a trusted WLAN, and the message may include information related to the ICM. Alternatively, if the E-UTRAN delivers a message to the terminal, the message used by the MME may be a Modify EPS bearer context request, and the message may include information related to ICM.

In operation 930, the user terminal 902 may update a mode for IP flow mobility according to the ICM included in the received message. The updated information may be applied to the entire PDN, or the updated information may be applied only to the PDN connection currently connected to the PDN connection of the user terminal 902.

In operation 935, the user terminal 902 may transmit a response message to the MME / WLAN 904. The response message may be one of a WLCP or NAS message according to the receiving node.

In step 940, the MME / WLAN 904 may transmit a response message to the PGW 906 in response to the message received in step 920. According to an embodiment, the response message may be an update bearer response message.

Referring to FIG. 10, in an embodiment, at least one of the user terminal 1002, the WLAN 1004, the PGW 1006, or the PCRF 1008 may transmit and receive signals with at least one of other entities.

In step 1010, the user terminal 1002 is registered in the operator's network, and a node capable of initiating IP flow mobility is determined. The method of determining a node capable of IP flow initiation in an embodiment may include an embodiment disclosed herein or a method other than the embodiment.

In operation 1015, the node of the operator network, for example, the PCRF 1008 may determine to change the ICM for the user terminal 1002. In an embodiment, the node of the provider network may determine to change the ICM for the user terminal 1002 based on at least one of a local configuration of the PCRF 1008, a network state, or information received from a subscription information server. . In addition, the ICM may be information set for each PDN connection.

In step 1020, the PCRF 1008 sends a message to the WLAN 1020 to update the ICM. In an embodiment, the message used to update the ICM may be a message using a Diameter protocol such as Credit-Control Answer (CCA), Re-Auth Answer (RAA), or Authentication-Information Answer (AIA). May include information related to ICM to be applied by the user terminal 1002.

In step 1025, the WLAN 1004 sends a request message to the PGW 1006 to change the ICM. The message may be a PBU message, which may include information related to the ICM. The information related to the ICM may be determined based on one of the information received in step 1020.

In operation 1030, the PGW 1006 may determine an ICM for the user terminal 1002 based on at least one of the received information. In an embodiment, the PGW 1006 may determine an ICM for the user terminal 1002 based on at least one of a local configuration of the PGW, a network state, or information received from a subscription information server. In an embodiment, the ICM may be information set for each PDN connection.

In step 1035, the PGW 1008 sends a message to the WLAN 1004 to inform the determined ICM about the user terminal 1002. The message for notifying the ICM determined in the embodiment may be a PBA, and this message may include the ICM for the user terminal 1002. The determined ICM may be the same ICM or modified ICM as the ICM previously applied to the terminal.

In operation 1040, the WLAN 1004 may transmit a request message to change the ICM to the user terminal 1002. In an embodiment, the message used to change the ICM applied to the user terminal 1002 may be a message using the WLCP protocol or an Update Connection Request when the WLAN 1004 is a trusted WLAN, and the message may include the ICM.

In operation 1045, the user terminal 1002 may update a mode for IP flow mobility according to the ICM included in the received message. The updated information may be applied only to the PDN connection that is currently the target of the PDN connection of the user terminal.

In operation 1050, the user terminal 1002 may transmit a response message to the WLAN 1004.

In the above embodiments of the present invention, it is proposed to control the PDN connection to determine the subject that triggers (trigger or initiation) to modify or generate a routing rule for performing IP flow mobility between the user terminal and the NW. . However, in an embodiment, the user terminal and the NW negotiate a right to modify or generate a rule for performing IP flow mobility, and operating accordingly may be applied to another control unit, for example, EPS bearer or IP flow. More specifically, the unit controlled to perform IP flow mobility according to an embodiment of the present disclosure may be a PDN connection, an EPS bearer, or an IP flow.

In the embodiment, when the control is applied for each EPS bearer, the negotiation of control authority between the user terminal and the NW may be performed during the process of generating the EPS bearer or modifying the context of the generated EPS bearer. In addition, in an embodiment, an operation for performing IP flow mobility for each EPS bearer may be performed before and after a process of generating or modifying an EPS bearer.

That is, the session management request message and the response message exchanged between the user terminal and the NW include information indicating whether it is allowed for the NW, the user terminal, or both to request IP flow mobility or create / modify a rule for the EPS bearer. Included.

In addition, in the embodiment, when the control is applied for each IP flow, the control may be performed during the process of exchanging information on the IP flow between the user terminal and the NW. In addition, in an embodiment, an operation for performing IP flow mobility may be performed before and after a process of exchanging information on IP flow.

That is, the session management request message and response message for exchanging information about the IP flow, that is, routing rule between the user terminal and the NW, request IP flow mobility for a specific IP flow (or a set of IP flows) or perform a rule. Information indicating whether creation / modification is allowed to the NW, the user terminal, or both may be included. The permission information may be included as an element of the routing rule. That is, the information constituting the routing rule containing the control information on the IP flow includes information indicating whether the user terminal is authorized or prohibited to initiate modification or update of the routing rule. Can be. The user terminal may perform a request process for modifying / updating a routing rule only if modification is allowed for a specific routing rule.

Meanwhile, when describing the above embodiments, initiating mobility for a specific IP flow may include performing at least one of creating, modifying, and deleting a routing rule for a specific IP flow.

In addition, in the above embodiments, it has been described that the user terminal and the NW are allowed to exchange mobility for a specific IP flow with each other. However, the permission may be replaced with a priority concept. More specifically, the information negotiated between the user terminal and the NW (using the procedure described in the above embodiments) may include a priority for an IP flow mobility or routing rule between the user terminal and the NW, If all or part of the routing rules exchanged with each other collide, or if the user equipment and the NW initiate the IP flow mobility process at the same time, it means that the operation is based on the request of the higher priority. For example, if a higher priority is given to the NW than the user terminal, the IP flow mobility process instigated by the NW and the user terminal is in conflict, and the routing rule needs to be created or modified, the NW sets the routing rule by the initiation process. It is to apply first. The priority information may be set according to message transmission or reception by the user terminal or the NW, or may be set in a form of changing the priority according to a specific condition. More specifically, the priority information may be set in the process of exchanging information related to the IFOM, and may include information of the priority of the node controlling the IFOM.

Embodiments herein relate to the UE and the NW explicitly negotiating a mode related to IFOM operation and operating according to the negotiated result.

One of the gist of the present invention transmits and negotiates or negotiates information related to which node is a node performing IP flow mobility or triggering IP flow mobility during the NW with the user terminal, and the node determined according to the present invention is IP. This includes performing or triggering flow mobility. Therefore, the gist of the present invention can be applied even when information indicating that the terminal and the NW negotiate IP flow mobility is not explicitly exchanged. More specifically, it is determined whether one of the terminal and the NW transmits a message related to the request IP flow mobility to the counterpart node, and whether to initiate the IP flow mobility according to the message received from the counterpart node. Can be.

Hereinafter, a method for determining whether a user terminal and an NW are allowed to initiate IP flow mobility according to an embodiment of the present disclosure will be described.

FIG. 13 is a diagram illustrating a method for transmitting and receiving a signal related to initiation of IP flow mobility between a terminal and a network according to an embodiment of the present disclosure.

Referring to FIG. 13, the user terminal 1302 and the PGW 1304 may transmit and receive a signal. The user terminal 1302 and the PGW 1304 may transmit and receive a signal through a base station (not shown). In an embodiment, the PGW 1304 may be referred to as an NW, which may be another network constituting the core network.

In operation 1310, the user terminal 1302 may transmit a message for requesting IP flow mobility to the NW 1304. The transmitted message may be a session management request message. This request may be made when information that can be used when determining IP flow mobility inside the user terminal 1302, for example, an ANDSF policy, an operator policy, or a user preference is set to a specific value. In addition, the request message transmitted by the user terminal 1302 to the NW 1304 may include at least one of information on an IP flow that is a request target and information related to a policy used by the user terminal 1302. In an embodiment, the information related to the policy may include whether the user terminal 1302 has an ANDSF policy and specific information on the ANDSF policy.

In operation 1315, the NW 1304 may determine whether to accept the IP flow mobility request received from the terminal 1302 based on at least one of the request, received information, local configuration, and subscription information of the user terminal 1302. have. In addition, in an embodiment, whether to accept or reject the request may be transmitted to the user terminal 1302 through a session management (SM) message.

In an embodiment, when the NW 1304 rejects the request, in step 1320, the NW 1304 may transmit a reject message to the user terminal 1302, and the reject message may be a session management reject message. According to an embodiment, the session management reject message may include a timer value.

In step 1325, if the user terminal 1302 does not accept the request, the NW 1304 initiates IP flow mobility instead of directly initiating IP flow mobility by the user terminal 1302 for the corresponding IP flow. You can decide that you should. That is, the rejection of the request of the user terminal 1302 by the NW 1304 may indicate that the result of negotiating an operation mode with the user terminal 1302 is NW_only mode. Accordingly, when the user terminal 1302 receives the rejection of the request, the user terminal 1302 may determine to operate in the NW_only mode. In addition, the result of the mode negotiation may be applied only to the IP flow that was the target when the user terminal 1302 requests IP flow mobility. Alternatively, the mode negotiation result may be applied to all PDN connections including IP flow. As described above, the operation mode may be determined based on the response result of the IP flow mobility without the explicit exchange of information between the user terminal 1302 and the NW 1304. In addition, the embodiment of FIG. 13 may be applied while the operation mode is negotiated between the user terminal 1302 and the NW 1304 and is operating in the negotiated operation mode through another embodiment of the present specification. As such, when the mode needs to be selectively changed during operation, the operation mode may be changed by transmitting a rejection message or an acknowledgment message to the counterpart node. In addition, based on the timer value included in step 1320, it is possible to determine a time for which the operation mode determined according to the session management reject message is maintained. In an embodiment, in response to receiving a session management reject message including the timer value, the user terminal 1302 drives a timer having the timer value, and an operation mode according to the session management reject message is valid until the timer expires. It can be judged that.

14 is a diagram illustrating another method of transmitting and receiving a signal related to initiation of IP flow mobility between a terminal and a network according to an embodiment of the present disclosure.

Referring to FIG. 14, the user terminal 1402 and the PGW 1404 may transmit and receive signals. The user terminal 1402 and the PGW 1404 may transmit and receive signals through a base station (not shown). In an embodiment, the PGW 1404 may be referred to as an NW, which may be another network constituting the core network.

In an embodiment, if the NW 1404 initiates IP flow mobility, the user terminal 1402 may also reject the IP flow mobility request of the NW.

More specifically, in step 1410, the NW 1404 may transmit a message for requesting IP flow mobility to the user terminal 1402. The transmitted message may be a session management request message. In addition, the request message may include information on the IP flow that is the target of the request. In addition, the request message may be selectively transmitted according to the subscription information of the user terminal 1402.

In operation 1415, the user terminal 1402 may determine whether to accept or reject the received request message. In the embodiment, the rejection of the NW request by the user terminal 1402 is based on at least one of a wireless channel state or congestion state detected by the user terminal 1402, an ANDSF policy and a user preference that the user terminal 1402 is using. Can be done.

If the user terminal 1402 rejects the request, the user terminal 1402 may transmit a message for rejecting the request to the NW 1404 in step 1420. In an embodiment, the message for rejecting the request may be a session management reject message. According to an embodiment, the session management reject message may include a timer value. In addition, the message for rejecting the request may include a reason for rejection of the user terminal 1402 (for example, a bad channel state, or cannot be performed by ANDSF policy). The cause may be communicated up to NW 1404.

If the NW 1404 does not accept the request, the NW 1404 determines that the UE 1402 initiates IP flow mobility, rather than the NW 1404 initiating IP flow mobility for the IP flow in step 1425. can do.

That is, in the embodiment, denying the request of the NW 1404 by the user terminal 1402 may indicate that the result of negotiating an operation mode between the NW 1404 and the user terminal 1402 is UE_only mode. Accordingly, the NW 1404 may determine that the UE_only mode should be operated when the rejection of the request is received. The results of this mode negotiation apply only to the IP flow that was targeted when the NW requested IP flow mobility. Or, it may be applied to all PDN connections including the IP flow.

As described above, the operation mode may be determined based on the response result of the IP flow mobility without the explicit exchange of information between the user terminal 1402 and the NW 1404. In addition, the embodiment of FIG. 14 may be applied while the operation mode is negotiated between the user terminal 1402 and the NW 1404 through another embodiment of the present specification and is operating in the negotiated operation mode. As such, when the mode needs to be selectively changed during operation, the operation mode may be changed by transmitting a rejection message or an acknowledgment message to the counterpart node. In addition, based on the timer value included in step 1420, it is possible to determine a time for which the operation mode determined according to the session management reject message is maintained. In an embodiment, in response to receiving the session management reject message including the timer value, the NW 1402 drives the timer having the timer value, and the operation mode according to the session management reject message is valid until the timer expires. You can judge.

Meanwhile, in the two embodiments of FIGS. 13 and 14, an initial operation mode of the user terminal and the NW may be an NW and UE mode. If the operation mode is initialized by the timer expiration, the operation mode of the user terminal and the NW may be changed to the NW and UE mode, and thus IP flow mobility may be initiated at both the NW and the user terminal side. In addition, in the above two embodiments, when a timer value is included in the request reject message, the entity receiving the request reject message may determine that an operation mode is determined according to the request reject message.

On the other hand, not only the present embodiment but also the overall embodiment of the present specification, after the operation mode related to IP flow mobility is set, initializing the operation mode or performing a renegotiation process may be performed using a timer. If the IP flow mobility request of the user terminal is rejected and operated in NW_only mode, the user terminal starts a timer upon receiving a message and determines that the negotiated mode is valid until the timer expires. If the timer expires, the negotiated mode can be reset or a renegotiation process can be performed. In addition, the timer value may be included in the rejection message and transmitted to the receiving entity when the entity rejecting the request is determined. As such, by passing the same timer value, a timer having the same value can be driven between the two entities.

On the other hand, the IP flow mobility started by the user terminal described above may be applied when there is a policy (policy), rules, or configuration that can be used when performing the IP flow mobility to the user terminal. Similarly, IP flow mobility initiated by the NW may be applied when there are policies that the NW can use to perform IP flow mobility, such as extended PCC rules.

If there is information that can perform IP flow mobility in both the user terminal and the NW, through the embodiments of the present specification, the user terminal and the NW can negotiate which entity can be the subject for IP flow mobility. have. At this time, the following priority may be used.

If the user terminal has information for performing IP flow mobility (at least one of ANDSF policy, user preference, and local operating environment), information for performing IP flow mobility in NW (for example, IP flow mobility) PCC rule) is characterized by using UE initiated IP flow mobility (ie, negotiating in UE-only mode, or operating in UE and NW mode).

To this end, the UE may include information indicating that it has information or a policy (eg, ANDSF policy) capable of performing IP flow mobility in a session management message (PDN connectivity request, etc.) transmitted to the provider network. have. The user terminal provides information indicating the type of information (one of ANDSF policy, user preference, and local operating environment) that it has, or information indicating whether it received from HPLMN or RPLMN if ANDSF policy exists. You can send additionally.

Apart from this, the user terminal may request the use of the UE-only mode only if it has information or policy capable of performing IP flow mobility. That is, the user terminal is allowed to request the use of the UE-only mode to the NW only if it has a valid ANDSF policy.

If there is no rule to use when performing IP flow mobility in the NW, the NW allows a user terminal request (using UE-only mode).

If the user terminal has information or policy that can use IP flow mobility, and if there is a rule that can be used for IP flow mobility in the NW as well, then the NW is the subject that provided the type and information of the user terminal (HPLMN). Or VPLMN), and the user's subscription information and the local configuration of the NW.

More specifically, assuming that the user terminal receives from HPLMN (H-ANDSF) or has a policy set by HPLMN, if the user terminal is roaming (connected to VPLMN), IP flow mobility is performed to the NW. If there is a rule that can be made and the current PDN connection is created as a local breakout (LBO), the NW of the VPLMN considers the roaming agreement with the HPLMN and the local configuration, so that the terminal's information (ie, UE-initiated NBIFOM is used). Decide whether to use). At this time, the user terminal described above uses IP flow mobility related information (ANDSF policy and service provider type) provided through the session management message. In general, in the above situation, the information provided by the HPLMN to the UE may have a higher priority than the NW rule.

As in the above embodiment, assuming that the user terminal receives from the HPLMN (H-ANDSF) or has a policy set by the HPLMN, if the user terminal is roaming (accessed to VPLMN), IP flow mobility is applied to the NW. If there is a rule that can be executed and the current PDN connection is created as Home Routed (HR), the NW of HPLMN considers the roaming agreement with the VPLMN and local configuration in consideration of the terminal information (that is, UE-initiated NBIFOM). Use). At this time, the user terminal described above uses IP flow mobility related information (ANDSF policy and service provider type) provided through the session management message. In general, in this situation, the rule of the NW of the HPLMN may have a higher priority than the information provided to the terminal.

Assume that the user terminal receives from the VPLMN (V-ANDSF) or has a policy set by the VPLMN. If the user terminal is roaming (accessed to VPLMN), and there is a rule to perform IP flow mobility in the NW, and the current PDN connection is created as Home Routed (HR), the NW of the HPLMN is the VPLMN. Considering both roaming agreement and local configuration of the UE, it is determined whether to use the UE information (ie, UE-initiated NBIFOM). At this time, the user terminal described above uses IP flow mobility related information (ANDSF policy and service provider type) provided through the session management message. In general, in this situation, the rule of the NW of the HPLMN may have a higher priority than the information provided to the terminal.

Like the above embodiment, if the user terminal receives from the VPLMN (V-ANDSF) or has a policy set by the VPLMN, if the user terminal is roaming (connected to the VPLMN), the IP flow mobility to the NW If there is a rule that can be executed and the current target PDN connection is created as Local Breakout (LBO), the NW of the VPLMN considers the roaming agreement with HPLMN and local configuration in consideration of the terminal information (ie UE-initiated NBIFOM). Can be used). At this time, the user terminal described above may use IP flow mobility related information (ANDSF policy and service provider type) provided through the session management message. In general, in this situation, the rule of NW of the VPLMN may have a higher priority than the information provided to the terminal.

On the other hand, when both the user terminal and the NW have information to use when performing IP flow mobility, deciding which to use first is high priority to information (for example, ANDSF policies such as ISRP and ISMP) of the user terminal. You can decide by ranking. This is because the ANDSF policy and the information set in the user terminal may be specific, and state information that can be directly measured by the user terminal, for example, a congestion state or a channel state may be considered. That is, if the user terminal requests the use of the UE-only mode, the NW may select the IP flow mobility mode according to the request of the user terminal. In this case, the user terminal may include information indicating that the reason for the UE-only mode request is that information for performing IP flow mobility is set in the user terminal, and may include information in the session management request message.

If the NW requests the UE to use the NW-only mode, the UE may determine whether to accept the request in consideration of the NW request and the information of the UE, that is, ANDSF policy, user preference, and local configuration. The user terminal may refuse to use the NW-only mode of the NW, and may transmit the reason information indicating the reason for the rejection in the session management rejection message. For example, if the user terminal has a valid ANDSF policy, the user terminal may refuse to use the NW-only mode of the NW, and at this time, a session management rejection message indicating reason information indicating that the rejection was rejected due to the ANDSF policy. Include it in Similarly, when the use of the NW-only mode is not allowed by the user preference, the UE may inform the reason while rejecting the use of the NW only mode.

Meanwhile, the user terminal may reject the NW request due to a congestion state or a channel (radio state or coverage loss) state. The NW request is an IP flow mobility command after negotiating NW-only mode or requesting NW-only mode. If the user terminal rejects the NW request, the user terminal manages the session including reasons for rejection (when the congestion state of the target access network is above a certain level, the channel state is below a certain level, or coverage loss occurs). A reject message can be sent to the NW.

Referring to FIG. 11, the terminal 1100 of the embodiment may include at least one of a transceiver 1102, a storage 1104, and a terminal controller 1106.

The transceiver 1102 may transmit and receive signals with other entities. In another embodiment, the other entity may include at least one of a base station and a wireless LAN, and may transmit and receive information to and from a core network node through the other entity.

The storage unit 1104 may store at least one of information related to an operation of the terminal 1100 and information transmitted and received through the transceiver 1102.

The terminal controller 1106 may control the transceiver 1102 and the storage 1104, and control the operation of the terminal disclosed in the embodiment.

12 is a diagram illustrating a core network entity according to an embodiment of the present specification. The core network entity may be at least one of a base station, WLAN, MME, SGW, PGW or PCRF.

12, the core network entity 1200 of the embodiment may include at least one of a transceiver 1202, a storage 1204, or a core network entity controller 1206.

The transceiver 1202 may transmit and receive a signal with another entity. In another embodiment, the other entity may include at least one of a terminal, a base station, a WLAN, an MME, an SGW, a PGW, or a PCRF.

The storage unit 1204 may store at least one of information related to an operation of the core network entity 1200 and information transmitted and received through the transceiver unit 1202.

The core network entity controller 1206 may control the transceiver 1202 and the storage 1204, and control the operation of the core network entity disclosed in the embodiment.

In the above embodiments, all steps may optionally be subject to performance or to be omitted. In addition, in each embodiment the steps do not necessarily have to occur in order and may be reversed. On the other hand, the embodiments of the present specification disclosed in the specification and drawings are merely presented specific examples to easily explain the technical contents of the present specification and help the understanding of the present specification, and are not intended to limit the scope of the present specification. That is, it will be apparent to those skilled in the art that other modifications based on the technical spirit of the present disclosure may be implemented.

On the other hand, the present specification and the drawings have been described with respect to the preferred embodiments of the present invention, although specific terms are used, it is merely used in a general sense to easily explain the technical details of the present invention and help the understanding of the invention, It is not intended to limit the scope of the invention. It will be apparent to those skilled in the art that other modifications based on the technical idea of the present invention can be carried out in addition to the embodiments disclosed herein.

Claims

In the method of transmitting and receiving signals in a terminal of a mobile communication system,

Transmitting a connection request message including request information for IP flow control to a packet data network gateway (PGW);

Receiving a connection response message including authorization information for IP flow control from the PGW; And

And controlling the IP flow associated with the connection based on the admission information for the IP flow control.
The method of claim 1,

Controlling the IP flow

Transmitting a message for moving an IP flow to the PGW based on the admission information for controlling the IP flow; or

And receiving a message for moving an IP flow from the PGW based on the admission information for controlling the IP flow.
The method of claim 1,

Controlling the IP flow

And controlling the connection in a PDN connection unit, a bearer unit, or an IP flow unit based on the grant information for the IP flow control.
In the signal transmission and reception method in a packet data network gateway (PGW) of a mobile communication system,

Receiving a connection request message including request information for IP flow control from a terminal;

Transmitting a connection response message including authorization information for IP flow control to the terminal; And

And controlling the IP flow associated with the connection based on the admission information for the IP flow control.
The method of claim 4, wherein

Controlling the IP flow

Transmitting a message for moving an IP flow to the terminal based on the admission information for controlling the IP flow; or

And receiving a message for moving the IP flow from the terminal based on the admission information for controlling the IP flow.
The method according to claim 1 or 4,

The acknowledgment information for controlling the IP flow includes a node information for controlling IP flow movement.
The method of claim 4, wherein

Controlling the IP flow

And controlling the connection in a PDN connection unit, a bearer unit, or an IP flow unit based on the grant information for the IP flow control.
In the terminal of the mobile communication system,

Transmitting and receiving unit for transmitting and receiving a signal; And

Control the transceiver, transmit a connection request message including request information for IP flow control to a packet data network gateway (PGW), receive a connection response message including authorization information for IP flow control from the PGW; And a controller configured to control an IP flow related to the connection based on the approval information for controlling the IP flow.
The method of claim 8,

The control unit

Transmitting a message for moving an IP flow to the PGW based on the grant information for the IP flow control, or receiving a message for moving the IP flow from the PGW based on the grant information for the IP flow control. Terminal.
The method of claim 8,

The acknowledgment information for the IP flow control is characterized in that it comprises node information for controlling the IP flow movement.
The method of claim 8,

The control unit

The terminal characterized in that for controlling the connection in PDN connection unit, bearer unit or IP flow unit based on the authorization information for the IP flow control.
In a packet data network gateway (PGW) of a mobile communication system,

Transmitting and receiving unit for transmitting and receiving a signal; And

Control the transceiver unit, receive a connection request message including request information for IP flow control from the terminal, transmit a connection response message including the authorization information for IP flow control to the terminal, the IP flow control PGW including a control unit for controlling the IP flow associated with the connection based on the approval information for.
The method of claim 13,

The control unit

Characteristic for transmitting the IP flow movement to the terminal based on the approval information for the IP flow control, or receiving a message for the IP flow movement from the terminal based on the approval information for the IP flow control. PGW.
The method of claim 13,

The approval information for controlling the IP flow includes the node information for controlling the IP flow movement.
The method of claim 13,

The controller controls a connection in a PDN connection unit, a bearer unit, or an IP flow unit based on the grant information for the IP flow control.