KR102367148B1 - Method and apparatus for improving internet communications - Google Patents

Abstract

An embodiment of the present invention provides a method and apparatus for improving communication efficiency. An embodiment of the present invention provides a method and apparatus for receiving user data or SMS using a control plane. An embodiment of the present invention provides a method and apparatus for creating a new radio bearer, changing a scheduling order of a bearer, omitting generation of an unnecessary bearer, or releasing an unnecessary connection state between a terminal and a base station.

Description

METHOD AND APPARATUS FOR IMPROVING INTERNET COMMUNICATIONS

The present invention relates to a method and apparatus for increasing the effectiveness of Internet communication. In more detail, the present invention relates to a method and apparatus for effectively exchanging information between nodes in a wireless communication system in order to increase the effectiveness of Internet communication.

In general, a wireless communication system has been developed to provide a voice service while ensuring user activity. However, the wireless communication system is gradually expanding its scope not only to voice but also to data services, and has now developed to the extent that it can provide high-speed data services. However, in a wireless communication system in which a service is currently provided, a more advanced wireless communication system is required because there is a shortage of resources and users demand a higher speed service.

In response to these needs, various RAN (Radio Access Network)-based technologies such as E-UTRAN/UTRAN/GERAN have been standardized in the 3rd Generation Partnership Project (3GPP) as a wireless communication system.

A 3GPP standard-based communication system can support various types of services and types of terminals. For example, it is possible to support communication of not only a communication terminal directly used by a person, such as a smartphone, but also an Internet of Things (IoT) terminal with little or no human intervention. In addition, it is possible to support a communication service that starts from voice and multimedia services, manages a terminal (Device Management), delivers specific information to a terminal, or collects specific information from a terminal.

On the other hand, when the number of devices using the Internet of Things increases, the rate of exchanging SMS and data between devices using IoT may increase. In this case, other services provided by the terminal to provide a message service quality may be reduced.

The technical problem to be achieved by the present invention is to provide a method and apparatus for increasing the effect of Internet communication. The present invention provides a method and apparatus for effectively exchanging information between nodes in a wireless communication system in order to increase the effectiveness of Internet communication.

In addition, the present invention provides a method and apparatus for controlling so that the quality of various services provided by a communication system is not deteriorated when the number of terminals transmitting and receiving messages through the operator network is large or when the complexity of the system increases due to this. .

In addition, the present invention provides a method and apparatus for controlling so that Internet quality is not deteriorated due to SMS or data exchange when the number of terminals transmitting and receiving messages through a business network is large due to the commercialization of the Internet of Things (IoT) do.

According to an embodiment of the present invention, in a method for improving communication efficiency of a mobility management entity (hereinafter referred to as MME), an attach request or a tracking area update (hereinafter, TAU) request from a base station to a terminal Receiving a message, transmitting a location area update message to a home subscriber server (hereinafter referred to as HSS) based on the request message, a user data signaling radio bearer of the terminal from the HSS , UDSRB) receiving subscriber information including support indication information, and determining whether to apply UDSRB to the terminal based on the subscriber information.

According to an embodiment of the present invention, in a device of a mobility management entity (hereinafter referred to as MME) for improving communication efficiency, an attach request or a tracking area update from a communication unit and a terminal communicating with at least one network node Receives a tracking area update (TAU) request message, transmits a location area update message to a home subscriber server (HSS) based on the request message, and receives user data signaling radio of the terminal from the HSS A device comprising: a controller for receiving subscriber information including user data signaling radio bearer (UDSRB) support indication information, and controlling whether to apply UDSRB to the terminal based on the subscriber information provides

According to an embodiment of the present invention, in a method for improving communication efficiency of a base station, an attach request or tracking area update (TAU) request message received from a terminal is transmitted to a mobility management entity, hereinafter MME), receiving a terminal context setup message including information indicating whether user data signaling radio bearer (UDSRB) is supported for the terminal from the MME, the terminal context A radio bearer for transmitting and receiving user data through a control plane (control plane), comprising the steps of configuring a UDSRB in the terminal based on a configuration message and transmitting and receiving user data using the configured UDSRB ( It provides a method characterized in that it is a radio bearer).

In addition, according to an embodiment of the present invention, in a base station apparatus for improving communication efficiency, an attach request or a tracking area update received from a communication unit and a terminal communicating with at least one network node or a tracking area update (hereinafter, referred to as Tracking Area Update) TAU) transmits a request message to a mobility management entity (hereinafter referred to as MME), and includes information indicating whether or not to support a user data signaling radio bearer (UDSRB) for the terminal from the MME and a control unit configured to receive a terminal context setup message, configure a UDSRB in the terminal based on the terminal context setup message, and transmit/receive user data using the configured UDSRB, wherein the UDSRB transmits user data to a control plane It provides an apparatus, characterized in that it is a radio bearer (radio bearer) for transmitting and receiving through (control plane).

Further, according to an embodiment of the present invention, in a method for improving communication efficiency of a terminal, an attach request including user data signaling radio bearer (UDSRB) request information or tracking area update (tracking) Transmitting an Area Update, hereinafter TAU) request message, receiving the UDSRB configuration information from the base station, generating a UDSRB based on the UDSRB configuration information, and using the generated UDSRB control plane (control plane) ) to provide a method comprising the step of receiving user data through.

Further, according to an embodiment of the present invention, in a method for improving communication efficiency of a terminal, an attach request including user data signaling radio bearer (UDSRB) request information or tracking area update (tracking) Transmitting an Area Update, hereinafter TAU) request message, receiving the UDSRB configuration information from the base station, generating a UDSRB based on the UDSRB configuration information, and using the generated UDSRB control plane (control plane) ) to provide a method comprising the step of receiving user data through.

According to an embodiment of the present invention, it is possible to provide a method and an apparatus for enhancing the effect of Internet communication. According to an embodiment of the present invention, a method and apparatus for effectively exchanging information between nodes in a wireless communication system can be provided in order to increase the effectiveness of Internet or IoT communication.

Also, according to an embodiment of the present invention, it is possible to provide a method and apparatus for changing a service such as billing or traffic of a sponsored data service according to a contract between a service provider and a communication service provider and user activity.

1 is a diagram showing the structure of a communication system according to an embodiment of the present invention.
2 is a diagram illustrating operations of a user terminal and a communication system for message transmission according to an embodiment of the present invention.
3 is a diagram illustrating an embodiment of the present invention for processing when an MT SMS is generated according to an embodiment of the present invention.
4 is a diagram illustrating operations of a terminal and a network that process when a MO SMS occurs according to an embodiment of the present invention.
5 illustrates a process of establishing a radio bearer for user data transmission through a control plane according to an embodiment of the present invention.
6 illustrates the operation of a user terminal and a network for processing MT SMS when UDSRB is used according to an embodiment of the present invention.
7 illustrates the operation of a user terminal and a network for processing MO SMS when UDSRB is used according to an embodiment of the present invention.
8 shows an operation when the user terminal needs only data transmission/reception through the control plane without transmitting/receiving other PS data according to an embodiment of the present invention.
9 illustrates an operation of releasing an RRC connection when SMS transmission is completed according to an embodiment of the present invention.
10 is a block diagram illustrating a communication terminal according to an embodiment of the present invention.
11 is a block diagram illustrating a base station according to an embodiment of the present invention.
12 is a block diagram illustrating an MME according to an embodiment of the present invention.
13 is a diagram illustrating a network structure for providing a sponsored data service.
14 is a diagram illustrating a series of processes for providing a sponsored data service to a user according to an embodiment of the present invention.
15 is a diagram illustrating an operation in a case in which a charging key is not used as a modification of the embodiment of FIG. 14 .
16 is a diagram illustrating a method of additionally transmitting an address of a web service according to an embodiment of the present invention.
17 is a diagram illustrating an operation for providing a conditional free charging service according to an embodiment of the present invention.
18 is a diagram illustrating a process of changing a sponsored data service according to a user's activity.
19 is a diagram illustrating a method in which a user terminal transmits access information to a core network node using a PCO.
20 is a diagram illustrating another method in which a user terminal transmits access information to a core network node using a PCO.
21 is a diagram illustrating a method of calculating the volume of data transmitted/received from a user terminal to a sponsored data service and notifying the user according to an embodiment of the present invention.
22 is a diagram illustrating an operation of a user terminal when a sponsored data service is conditionally applied according to an embodiment of the present invention.
23 is a diagram illustrating an operation of a user terminal when a sponsored data service is conditionally applied according to an embodiment of the present invention.
24 is a diagram illustrating a method for a user terminal to receive and use information on a sponsored data service from an operator network.
25 is a diagram illustrating a method for a user terminal to receive and use real-time information on a sponsored data service from a network.
26 is a diagram illustrating characteristics of sponsored data service applications by a user terminal according to an embodiment of the present invention.

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

In describing the embodiments, descriptions of technical contents that are well known in the technical field to which the present invention pertains and are not directly related to the present invention will be omitted. This is to more clearly convey the gist of the present invention without obscuring the gist of the present invention by omitting unnecessary description.

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

Advantages and features of the present invention, and a method for achieving them will become 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 different forms, and only these embodiments allow the disclosure of the present invention to be complete, and common knowledge in the technical field to which the present invention belongs It is provided to fully inform the possessor of the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout.

At this time, it will be understood that each block of the flowchart diagrams and combinations of the flowchart diagrams may be performed by computer program instructions. These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, such that the instructions performed by the processor of the computer or other programmable data processing equipment are not described in the flowchart block(s). It creates a means to perform functions. These computer program instructions may also be stored in a computer-usable or computer-readable memory that may direct a computer or other programmable data processing equipment to implement a function in a particular manner, and thus the computer-usable or computer-readable memory. It is also possible that the instructions stored in the flow chart block(s) produce an article of manufacture containing instruction means for performing the function described in the flowchart block(s). The computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to create a computer or other programmable data processing equipment. It is also possible that instructions for performing the processing equipment provide steps for performing the functions described in the flowchart block(s).

Additionally, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). It should also be noted that in some alternative implementations it is also possible for the functions recited in blocks to occur out of order. For example, two blocks shown one after another may be performed substantially simultaneously, or the blocks may sometimes be performed in the reverse order according to a corresponding function.

At this time, the term '~ unit' used in this embodiment means software or hardware components such as FPGA or ASIC, and '~ unit' performs certain roles. However, '-part' is not limited to software or hardware. '~' may be configured to reside on an addressable storage medium or may be configured to refresh one or more processors. Accordingly, as an example, '~' indicates components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, and procedures. , subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functions provided in the components and '~ units' may be combined into a smaller number of components and '~ units' or further separated into additional components and '~ units'. In addition, components and '~ units' may be implemented to play one or more CPUs in a device or secure multimedia card.

In the following description of the embodiments of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted.

In addition, in describing the embodiments of the present invention in detail, the basic 3GPP (Third Generation Partnership Project) LTE system will be mainly targeted, but the embodiments of the present invention are other communication/computer systems having a similar technical background and system form. It is also applicable within a range that does not significantly depart from the scope of the present invention, and this will be possible at the discretion of a person having technical knowledge skilled in the technical field of the present invention.

For example, the present technology targeting an LTE system may be applied to a UTRAN/GERAN system having a similar system structure. In this case, the ENB (RAN node) may be replaced with RNC/BSC, the S-GW may be omitted or included in the SGSN, and the P-GW may correspond to the GGSN. In addition, the bearer concept of the LTE system may correspond to the PDP context of the UTRAN/GERAN system.

Meanwhile, in the description of the embodiments of the present invention, it will be assumed that the main target service is a short message service (hereinafter, SMS, Short Message Service). However, in the embodiments of the present invention, other data or message services, for example, IP-based data communication It can be applied to services as well within a range that does not significantly depart from the scope of the present invention, and this will be possible at the discretion of a person having technical knowledge skilled in the technical field of the present invention.

1 is a diagram showing the structure of a communication system according to an embodiment of the present specification. According to an embodiment, the communication system may be an LTE-based mobile communication system.

1, as shown, the radio access network of the LTE mobile communication system is a next-generation base station (Evolved Node B, EUTRAN, hereinafter referred to as ENB or Node B) 130 and MME (Mobility Management Entity) 150 and Consists of a Serving-Gateway (S-GW) 140 .

A user equipment (User Equipment, hereinafter referred to as UE) 100 accesses an external network through ENB 130 , S-GW 140 , and P-GW (PDN-Gateway) 160 . In order for the user terminal to transmit and receive data through the PGW, a PDN connection must be created, and one PDN connection may include one or more EPS bearers.

AF (Application Function) 110 is a device for exchanging application-related information at the user and application level.

The PCRF 120 is a device for controlling a policy related to the user's QoS (Quality of Service), and a Policy and Charging Control (PCC) rule corresponding to the policy is transmitted to the P-GW 160 is applied

ENB 130 is a RAN (Radio Access Network) node and corresponds to the RNC of the UTRAN system and the BSC of the GERAN system. The ENB 130 is connected to the UE 100 through a radio channel and performs a role similar to that of the existing RNC/BSC.

In LTE, all user traffic including real-time services such as VoIP (Voice over IP) through Internet protocol are serviced through a shared channel, so a device for scheduling by collecting situation information of UEs 100 is required. ENB 130 is responsible for this.

The S-GW 140 is a device that provides a data bearer, and creates or removes a data bearer under the control of the MME 150 .

The MME 150 is a device in charge of various control functions, and one MME 150 may be connected to a plurality of base stations.

PCRF (Policy Charging and Rules Function) 120 is an entity that collectively controls QoS and charging for traffic.

Meanwhile, although omitted in the drawings, the structure of the communication system may include a Mobile Switching Center (MSC) and a Gateway Mobile Switching Center (GMSC). The GMSC is a device that serves as a gateway to the operator network for a circuit switched (CS) service, for example, a voice service or an SMS (Short Messaging Service). The MSC is a device in charge of controlling the CS domain.

Hereinafter, a method and apparatus for enhancing the effect of Internet communication according to an embodiment of the present invention will be described. In order to increase the effect of Internet communication, the following embodiment will mainly describe a method and apparatus for effectively exchanging information between nodes in a wireless communication system. The following embodiment may be applied to a communication method of a communication device supporting the Internet of Things (IoT).

When the number of terminals transmitting and receiving messages through the operator network in the mobile communication system is large (for example, it may occur when the number of devices using IoT communication increases), or when the complexity of the system increases due to this, the communication system The quality of the various services provided by this may deteriorate. In an embodiment of the present invention, in order to solve this problem, a method and apparatus for improving communication efficiency in a situation in which the quality of a service provided by a communication system is deteriorated will be described.

If the number of terminals using a messaging service (eg, short text service, SMS) increases, request processing for another type of service (eg, voice service) is delayed in order to provide the messaging service, resulting in deterioration of service quality can be Accordingly, in a situation where the number of terminals using a messaging service increases, there is a need for a method and apparatus capable of not degrading the service quality of terminals receiving other types of services.

Meanwhile, when the user terminal switches from the idle state to the connected state to receive the messaging service, it may be wasteful to set a context for a service other than a context for supporting the messaging service. Accordingly, there is a need for a method and apparatus capable of selectively setting only a context for a messaging service when a user terminal does not receive a service other than the messaging service.

2 is a diagram illustrating operations of a user terminal and a communication system for message transmission according to an embodiment of the present invention. Referring to FIG. 2 , a communication system according to an embodiment of the present invention may include a terminal (UE) 210 , an eNB 220 , an MME 230 , an MSC 240 , and a GMSC 250 . The function of each entity is referred to the description of FIG. 1 .

The user terminal 210 is registered with the operator network and is in a state capable of receiving SMS (S201).

If the MT (Mobile Terminating) SMS for the user terminal 210 arrives at the GMSC 250 from the external network, the GMSC 250 sends a message to the MSC 240, for example, a Forward Short Message. The SMS is transmitted through (S211).

When the MSC 240 receives the SMS from the GMSC 250, the MSC 240 transmits a message informing the MME 230 that a service for the user terminal has occurred, for example, a SGs Service Request message (S213).

The MME 230 determines whether to perform paging according to the connection state of the user terminal 210 . If the user terminal 210 is in an idle state (mode), the MME transmits a paging message to the base station. If the user terminal 210 is in a connected state, steps S221 to S226 may be omitted. If the terminal 210 is in an idle state, the MME 230 may transmit a paging request message to the base station (S221).

Upon receiving the paging message from the MME 230, the base station 220 starts a paging process with the user terminal 210 (S223).

Upon receiving the paging message from the base station, the user terminal performs a random access process and a process of establishing an RRC connection ( S223 ).

When transmitting an RRC connection setup complete message during an RRC connection establishment process, the user terminal 210 includes a service request message and transmits it. The base station 220 transmits the service request message received from the user terminal 210 to the MME 230 (S224).

The MME 230 performs a process of installing the context of the user terminal in the base station 220 (S225).

The base station 220 performs a process of establishing a signaling bearer (SRB) and data radio bearing (DRB) with the user terminal according to the terminal context received from the MME 230 . During this process, SRB2 capable of transmitting a non-access layer (hereinafter, NAS, Non-Access Stratum) message is established (S226).

The MME 230 transmits to the MSC 240 a message for requesting a service for the user terminal 210, that is, SMS transmission in this embodiment, for example, a SGs Service Request message (S231).

The MSC 240 transmits the SMS received from the GMSC 250 to the MME 230, in which case the SMS may be transmitted while being included in the SGs Downlink Unidata message (S233).

The MME 230 transmits the SMS received from the MSC 240 to the terminal 210 through the base station 220 . At this time, the MME 230 transmits the NAS message (eg, Downlink NAS Transport or Downlink Generic NAS Transport) by including the SMS, and the NAS message is a message delivered to the base station, for example, the S1AP Downlink NAS Transport message. is included and delivered (S235). In 3GPP, although SMS is user data, not control messages, it is set to be transmitted using NAS messages.

The base station 220 transmits the Downlink NAS Transport message received from the MME 230 to the user terminal 210, and in this case, a DL Information Transfer message (SRB2) is used (S237).

The user terminal 210 transmits an ACK for receiving the SMS, which is transmitted back to the MSC 240 through the eNB 220 and the MME 230 (S241, S243, and S245). When the user terminal transmits the ACK, SRB2 (ULInformation Transfer message) is used.

The user terminal 210 transmits a delivery report indicating whether the received SMS has been properly stored, which is delivered back to the GMSC 250 through the eNB 220 , the MME 230 , and the MSC 240 . (S251, S253, S255, S257). When the user terminal transmits a delivery report, a ULInformation Transfer message (SRB2) is used.

Thereafter, the user terminal 210 receives an ACK for the delivery report again through SRB2.

Although the above embodiment describes the operation of the user terminal and the network in a situation where a mobile terminating (MT) SMS to the user terminal occurs, the user terminal and the network when a mobile originating (MO) SMS occurs The action is not very different. The difference is that the paging process is unnecessary in the above embodiment, the user terminal transmits the SMS to the GMSC through the base station, the MME, and the MSC, receives the ACK for the SMS from the GMSC, and the SMS delivery report (delivery) report) is received from the GMSC, and an ACK is transmitted to the GMSC. When the user terminal sends an ACK for an SMS or delivery report, an uplink message (ULInformation Transfer/Uplink NAS Transport) is used, and when receiving an ACK and a delivery report for the SMS, a downlink message (DLInformation Transfer/Downlink NAS Transport) is used. ) is used.

Also, in the above embodiment, it can be seen that a total of four NAS message transmissions (using SRB2) occur in order to transmit one SMS to the user terminal. Therefore, if the number of user terminals transmitting and receiving SMS increases, the transmission of NAS messages through SBR2 may become frequent. Accordingly, as the number of attempts to transmit an SMS increases, it may affect the performance of a general NAS procedure (TA update, ESM procedure, etc.) using the same SRB2. In particular, in the case of devices using IoT, it is predicted that SMS will be used as a communication means, and in this case, the quality of other services may be deteriorated due to frequent transmission and reception of SMS.

In addition, if the resource allocation priority of the base station for SRB2 is set higher than that of the DRBs, as SMS, which is a type of general user data, is transmitted through SRB2, the transmission delay of control messages transmitted through the DRB is reduced. can occur For example, if SMS and IMS-based services are supported through the operator network, and the number of SMS to be processed by the base station increases, the control message of the IMS-based service, for example, an Invite SIP message for initiating a voice call. Resource allocation of DRB may be delayed due to resource allocation for SRB2 for transmitting SMS. When such a situation occurs, call setup of a voice service sensitive to transmission delay may be delayed in order to transmit an SMS that is not sensitive to transmission delay. Likewise, when resource allocation for the DRB is delayed due to the increase in the number of SMS to be processed by the base station, the resource may not be smoothly allocated to an already established voice call (using the IMS media bearer), so that the voice service quality may be deteriorated.

Hereinafter, a method and an apparatus for solving the above problem will be described through examples.

In the first embodiment, if NAS message transmission (ie, message transmission through SRB2) is for user data, for example, SMS, the priority of LC (Logical Channel) for SRB2 for a preset time will lower it The priority may be a concept indicating the priority of resource allocation for the LC, and resource scheduling for the LC may be performed based on the priority. Instruction information or a priority value for indicating the priority may be used. For example, as the priority value is a smaller LC, resources may be allocated preferentially. The priority may indicate resource allocation priority for a plurality of LCs in the same terminal. In addition, the priority may indicate the resource allocation priority of the plurality of LCs for the plurality of terminals in the base station. The content of the priority may be applied to each of the embodiments of FIGS. 3 to 12 below.

Although the conventional NAS message type is not classified, the NAS message type can be classified in the embodiment of the present invention. The classification can be divided into a NAS message for user data (eg, data for SMS) and a general NAS message. In addition, in the case of NAS message transmission for user data, the priority of a logical channel (LC) for this may be adjusted. That is, the priority of a logical channel (LC) for SRB2 may be set to have a lower priority than LC for a general NAS message or DRB for a preset time. The priority may correspond to a scheduling order. In addition, a timer for setting a time for adjusting the priority may be additionally applied. Through this, it is possible to prevent another SRB2 (eg, NAS procedure) or DRB (eg, IMS signaling or media transmission) from not receiving resource allocation or from being delayed for SRB2 transmission generated for user data.

3 is a diagram illustrating an embodiment of the present invention for processing when an MT SMS occurs according to an embodiment of the present invention.

S301 to S333 of FIG. 3 are the same as S201 to S233 of FIG. 2 , so refer to the description of FIG. 2 .

The MME 330 is a message sent to the base station 320 for SMS transmission, for example, a Downlink NAS Transport message, the type of NAS message to be transmitted, that is, the NAS message to be transmitted is not a general EMM or ESM message. Information indicating that SMS (or user data or message) is included may be included (S335). This information may be configured in the form of information indicating the transmission priority of the NAS message including user information, not information indicating the type of the NAS message as described above. Also, a timer may be additionally included in the message. This timer is when the base station transmits an SMS (or user data or message) and then uses SRB2 to transmit messages related thereto. The time for temporarily lowering the scheduling priority of the LC (logical channel) of SRB2 is a value representing

The base station 320 identifies the type information or priority information of the NAS message in the DL NAS transport message received from the MME, and adjusts the priority of a logical channel (LC) corresponding to the bearer for transmitting the NAS message based on this. can be (S341). If the S1_AP message received from the MME 330, for example, a Downlink NAS Transport message, the type of NAS message is not a general EMM or ESM message, but is set to SMS (or user data or message), or NAS message When the transmission priority of is set to be low, the base station 320 may lower the scheduling (resource allocation) priority of the LC for SRB2 to be used when transmitting the corresponding NAS message for a preset time. In addition, if a timer value is included in the S1_AP message, for example, the Downlink NAS Transport message, the base station 320 starts a timer and lowers the scheduling priority of the LC for the SRB2. may be applied until the set timer expires. Reducing the scheduling priority of the LC for SRB2 may be applied not only to the downlink NAS message transmission, but also when the user terminal 310 requests resource allocation of the LC for SRB2 for the uplink NAS message transmission. Meanwhile, although it has been described above that the base station 320 receives the timer information from the MME, the base station 320 may set and start a timer by itself. For example, when the base station 320 analyzes information of the received DL NAS transport message, the NAS message type includes user data or includes information instructing to lower the priority of the NAS message, the base station This corresponding can set itself and start a timer to lower its priority.

The base station 320 may deliver the NAS message received from the MME 330 to the user terminal 310 based on the priority set above (S343). The user terminal 310 may transmit an uplink NAS message in response to the NAS message transmitted from the base station 320 (S351). The priority and timer settings for the logical channel (LC) may be applied to resource allocation of a logical channel (LC) for SRB2 during uplink transmission of the terminal 310 .

4 is a diagram illustrating operations of a terminal and a network that process when a MO SMS occurs according to an embodiment of the present invention.

The user terminal 410 is registered in the operator network and is in a state capable of transmitting and receiving data (S401).

A mobile originating (MO) SMS is triggered in the user terminal 410 (s411).

If the user terminal 410 is in an idle state, the user terminal 410 performs a process for establishing an RRC connection for SMS transmission (S413).

The user terminal 410 transmits a Service Request message to the MME 430 through the eNB 420 . This message is contained in an RRC Setup Complete message and transmitted to the base station 420, and the base station delivers it to the MME 430 (S415).

The MME 430 performs a process for installing the context of the user terminal in the base station 420 .

The base station 420 performs a process for installing a signaling radio bearer (SRB) and a data radio bearer (DRB) with the user terminal 410 based on the user terminal context received from the MME (S417). This process is an RRC connection reconfiguration process.

When the SRB2 setting is completed, the user terminal 410 may transmit a resource allocation request (SR, Scheduling Request, or BSR, Buffer Status Request) message for transmitting a message in an uplink (S421). The message may include information indicating that the type of NAS message to be transmitted, that is, the NAS message to be transmitted includes SMS (or user data or message) rather than a general EMM or ESM message. This information may be configured in the form of a transmission priority of a NAS message rather than information indicating a type of NAS message as described above. Also, a timer may be additionally included in the message. This timer is a value indicating the time for which the base station transmits SMS (or user data or message) and then needs to use SRB2 when transmitting related messages. .

The base station 420 knows that resource allocation for SRB2 is required, but identifies the type or priority information based on the SR or BSR message received from the terminal 410 . When the type of information included in the scheduling request message of the user terminal 410 is set to SMS (or user data or message) rather than a general EMM or ESM message, or the transmission priority of the NAS message is set low, The base station 420 may temporarily lower the scheduling (resource allocation) priority of the LC for SRB2 to be used when transmitting the corresponding NAS message. For example, the scheduling may be set to a lower priority than the order of logical channels (LCs) for other bearers. In addition, if a timer value is included in the S1_AP message, for example, the Downlink NAS Transport message, the operation of starting a timer and lowering the scheduling priority of the LC for the SRB2 is performed by the set timer (timer) ) can be applied until it expires. The timer information may be set and started by the base station 420 without receiving it from the terminal 410 .

The base station 420 notifies the user terminal of an uplink grant according to the scheduling result (S425).

The user terminal 410 transmits the NAS message including the SMS using the uplink resource allocated by the base station 420 (S431). This message is included in the RRC Information Transfer message and delivered to the base station 420 . The base station 420 extracts the NAS message from the RRC message received from the terminal 410 and delivers it to the MME 430 ( S433 ), and the MME 430 again extracts the SMS included in the NAS message and delivers it to the MSC 440 . do (S435). Finally, the SMS is transferred from the MSC 440 to the GSMC 450 (S437).

Meanwhile, in the above embodiment, SRB2 is used as it is when transmitting SMS, but a method of temporarily lowering the priority is used. In this case, since the user terminal must transmit the SMS using a NAS message, SRB2 when requesting resource allocation for the LC of SRB2 The priority of LCs for LC is adjusted. In the embodiment of the present invention, in addition to using SRB2, the user terminal requests the base station to allocate resources for a logical channel (LC) of another data radio bearer (DRB) instead of SRB2, and the uplink resource allocated from the base station. can also be used to send NAS messages, including SMS.

Hereinafter, a method for solving the above problem through the second embodiment of the present invention will be described. In this embodiment, a new type of radio bearer is introduced so that user data such as SMS can be transmitted and received through a control plane, a general control plane message (ie, EMM/ESM NAS) message) or DRB (Data Radio Bearer), which must have a high priority, to prevent the transmission quality from being degraded due to user data transmitted and received through the control plane such as SMS.

5 illustrates a process of establishing a radio bearer for user data transmission through a control plane according to an embodiment of the present invention. In describing this embodiment, a radio bearer for user data transmission through the control plane (NAS) is defined as a User Data Signaling Radio Bearer (UDSRB), but this is only a designation for convenience of description. , for example, may be defined as another name such as Signaling Radio Bearer 3 (SRB3).

The user terminal 510 may perform an RRC connection establishment process for performing a registration process (Attach or TA Update) (S501).

The terminal 510 may transmit an RRC setup complete or attach or a tracking area update request (TAU request) message to the MME 530 through the base station 520 (S503). In the RRC setup complete, attach or tracking area update (TA update) request message transmitted to the MME 530 , the user terminal 510 supports whether the user data signaling radio bearer (UDSRB) of the user terminal 510 is supported. Alternatively, information indicating a support request may be included.

The MME 530 may transmit an Update Location message for the user terminal 510 to a Home Subscriber Server (HSS) 560 (S507). The MME 530 may include information indicating whether the current network supports UDSRB in an Update Location message for the user terminal 510 transmitted to the HSS 560 . This information may indicate that the user terminal 510 supports UDSRB or may be included when information requesting UDSRB support is received from the user terminal 510 .

The HSS 560 may transmit an Update Location Ack (Ack) message including subscription information of the terminal 510 to the MME 530 (S509). The HSS 560 is the UDSRB for the user terminal in the subscription information (included in the Update Location Ack message) sent to the MME 530 if the user terminal is subscribed to support the UDSRB or subscribed to the service using the UDSRB. It may include information indicating that it is supported. In addition, the HSS 560 may include the basic QoS (Quality of Service) information (relative resource allocation priority, charging information, etc.) of the UDSRB along with the information to the MME 530 .

The MME 530 determines whether to apply the UDSRB to the user terminal 510 (S511). When determining whether to apply UDSRB, the MME 530 may consider whether or not to support UDSRB or whether to request a UDSRB received from the user terminal 510 and subscription information (whether to support UDSRB) received from the HSS.

Meanwhile, although it has been described above that information including whether the UE 510 supports UDSRB or whether UDSRB is requested is transmitted to the MME, the information may not be included in the Attach/TAU request process. In this case, the MME 530 may determine whether to apply the UDSRB based on the subscription information received from the HSS 560 .

When the MME 530 determines to apply the UDSRB to the user terminal 510, when the user terminal context is installed to the base station 520, it may include information indicating that the UDSRB is applied (S521). . To this end, the S1_AP message transmitted from the MME 530 to the base station 520 , for example, an initial UE context setup message may include information indicating that UDSRB is supported. In addition, when the MME 530 decides to support the UDSRB. It may include QoS information to be applied to the UDSRB together with the information, for example, relative resource allocation priority.

When the base station 520 needs to apply the UDSRB to the user terminal 510 , the base station 520 sets the UDSRB according to the user terminal context received from the MME 530 ( S531 ). Configuring the UDSRB includes generating LC (Logical Channel) information for the UDSRB. That is, a bearer context referred to as UDSRB is established between the MME and the UE, and UDSRB bearer establishment includes generating logical channel (LC) information corresponding to the UDSRB between the UE and the base station.

When applying the UDSRB to the user terminal 510 , the base station 520 transmits information for setting the UDSRB to the user terminal 510 ( S541 ). In this case, the information of the UDSRB may be delivered through an RRC connection reconfiguration message. For example, the SRB-ToAddMod field of the RadioResourceConfigDedicated IE of the RRC connection reconfiguration message may be used. At this time, in the LogicalChannelConfig field included in SRB-ToAddMode, the priority (priority) of the LC of the UDSRB may be specified. In this case, the priority of the UDSRB may be set to a lower priority than other SRBs. In addition, it may be set to a lower priority than the LC of the DRB that should have a high priority, for example, a DRB using QCI (QoS Class Identifier) 1 or QCI 5.

Upon receiving the UDSRB configuration information from the base station 520 , the user terminal 510 generates the UDSRB according to the configuration information. Thereafter, the SMS (or message) transmitted through the control plane may be transmitted using the UDSRB.

Meanwhile, in the above embodiment, information indicating that the user terminal supports UDSRB or requesting the use of UDSRB is transmitted to the core network (MME) through the NAS message, but this information may be transmitted to the core network through the base station using an RRC message. . In this case, the user terminal may deliver the information to the base station in the form of UE Radio Capability or FGI during an RRC connection creation process or a separate UE radio capability inquiry process. If the base station receives the information from the user terminal, the base station delivers it to the MME. In this case, an S1_AP message, for example, an Initial UE context setup response or a UE Radio Capability Match response message may be used.

6 illustrates the operation of a user terminal and a network for processing MT SMS when UDSRB is used according to an embodiment of the present invention.

Since S601 to S633 of FIG. 6 are similar to S201 to S233 of FIG. 2 , refer to the description of FIG. 2 .

The MME 630 may transmit a message to the base station 620 for SMS transmission (S641). The message may be, for example, a Downlink NAS Transport message. The MME 630 indicates that the message transmitted to the base station 620 includes the type of NAS message to be transmitted, that is, the NAS message to be transmitted is not a general EMM or ESM message, but includes SMS (or user data or message). Information may be included. This information may be configured in the form of information indicating the transmission priority of the NAS message, not information indicating the type of the NAS message as described above.

The base station 620 delivers the NAS message received from the MME 630 to the user terminal 610 . If the S1_AP message received from the MME 630, for example, a Downlink NAS Transport message, the type of NAS message is not a general EMM or ESM message, but is set to SMS (or user data or message), or NAS message If the transmission priority of is set low, the base station must use UDSRB, not SRB2, when transmitting the corresponding NAS message. In this case, the base station applies LC scheduling (resource allocation) to the UDSRB according to the context of the UDSRB (S643).

The base station 620 transmits the NAS message (including SMS) received from the MME 630 to the user terminal 610 using the allocated resource (S645). The RRC message (eg, DLDataTransfer message) used at this time is transmitted using UDSRB rather than SRB2.

On the other hand, if the user terminal 610 needs to transmit a packet for a response (ACK) or Delivery Report to the received SMS, the user terminal SR (scheduling request) or BSR (Buffer Status Request) of the LC to the UDSRB ) to request resource allocation.

The base station 620 may allocate an uplink grant (UL grant) to the user terminal by applying the LC scheduling for the UDSRB, as described above (S651).

7 illustrates the operation of a user terminal and a network for processing MO SMS when UDSRB is used according to an embodiment of the present invention.

Since S701 to S717 of FIG. 7 are similar to S401 to S417 of FIG. 4 , refer to the description of FIG. 4 .

In S719 , the base station 720 transmits information for UDSRB configuration to the user terminal 710 . This process is similar to the process S541 of FIG. 5 . In this case, information for UDSRB configuration may be delivered through an RRC connection reconfiguration message. In addition, it may be set to a lower priority than the LC of the DRB that should have a high priority, for example, a DRB using QCI (QoS Class Identifier) 1 or QCI 5.

When the UDSRB setting is completed, the user terminal 710 may transmit a resource allocation request (Scheduling Request or Buffer Status Request) message for transmitting a message in an uplink (S721). Since this request is for SMS (or data transmitted through the control plane) of the user terminal, it is for LC of UDSRB, not SRB2. That is, the LC referred to by the SR or the BSR should be configured for the UDSRB.

The base station 720 recognizes that resource allocation for the UDSRB is required, and performs scheduling according to LC information (priority, etc.) for the UDSRB. As a result of this scheduling, the UDSRB may not be allocated a resource preferentially over the LC of SRB0/1/2 or a high-priority DRB (eg, a DRB of a bearer having a QCI of 1 or 5) (S723).

The base station 720 notifies the user terminal 710 of the uplink grant according to the scheduling result.

The user terminal 710 transmits a NAS message including an SMS using an uplink resource allocated by the base station 720 (S731). This message is included in an RRC message, for example, a UL Data Transfer message and delivered to the base station 720 . The base station 720 extracts the NAS message from the RRC message received from the terminal 710 and delivers it to the MME 730 (S733), and the MME 730 again extracts the SMS included in the NAS message and delivers it to the MSC 740. do (S735). Finally, the SMS is transferred from the MSC 740 to the GSMC 750 (S737).

If the UDSRB described in the above embodiments is used, the user terminal transmits and receives data by using the user plane (using DRB) and using the control plane (using the UDSRB). can be distinguished. If only data transmission/reception through a control plane is required for the user terminal, there is no need to set the DRB information in the process of setting the context of the user terminal. That is, if data is transmitted/received using only UDSRB, unnecessary message exchange and message size can be reduced by omitting the process of setting up the DRB. A third embodiment of the present invention will be described with reference to FIG. 8 below.

8 shows an operation when the user terminal only needs data transmission/reception through a control plane without other PS data transmission/reception according to an embodiment of the present invention. Since operations S801 to S813 are similar to operations S201 to S213 of FIG. 2 , refer to FIG. 2 .

If a mobile terminating (MT) SMS (or data transmitted through a control plane) occurs for the user terminal 810 , the MME 830 provides the base station 820 to the control plane during the paging process. It transmits data including information indicating whether it is data information transmitted through or NAS user data (userdata) (S821).

When the base station 820 recognizes that paging for the MT SMS (or data transmitted through the control plane) has occurred through the information received from the MME 820, paging transmitted to the user terminal Data information transmitted through the control plane, for example, information indicating whether NAS user data (userdata) is included in the message is transmitted.

Based on the message received through S823, the user terminal 810 may know that SMS or data will be received through a control plane. In this case, the user terminal 810 determines whether there is general data to be transmitted/received, that is, data to be transmitted/received through a user plane (DRB) ( S831 ). The terminal 810 may determine whether to use only the UDSRB based on the determination result. In addition, the DRB generation process may be omitted.

When the terminal determines that there is no data to be transmitted/received through the user plane, the following operations S833 to S853 may be performed to receive the data. Even if the user terminal itself generates MO data to be transmitted through the control plane, the user terminal determines whether there is general data to be transmitted and received, that is, there is no data to be transmitted/received through the user plane (DRB). In this case, operations S833 to S853, which will be described later, may be applied to receive the data.

The user terminal 810 may inform the base station that the reason for creating the current RRC connection is data transmission/reception through a control plane during the process of creating the RRC connection 833(S). This may be accomplished by setting the establishment cause of the RRC Connection Request message to mo-NAS-userdata (in case of outgoing) or mt-NAS-userdata (in case of incoming).

The base station 820 can know from the information received from the user terminal 810 that the reason the user terminal 810 creates the RRC connection is data transmission and reception through a control plane. Through this, the base station can know that it is necessary to set a context for the UDSRB and that it is unnecessary to set a context for another DRB (S835).

The base station 820 and the terminal 810 may create an RRC connection through S827 and S839.

After the RRC connection is created, the base station 820 transmits an initial UE message to the MME 830 (S841). When the initial UE message is transmitted, information indicating that the received user terminal 810 generates the RRC connection is data transmission/reception through a control plane may be transmitted. For example, the base station 820 may transmit the RRC establishment cause (mo-NAS-userdata or mt-NAS-userdata ) together. Through this, the MME 830 can know that the context (context) setting for the UDSRB is necessary for the user terminal and that the context (context) setting for the other DRB is unnecessary.

On the other hand, the user terminal 810 includes information indicating that a data transmission/reception service is requested through a control plane in an initial UE message sent to the MME 830, for example, a Service Request message. can be transmitted Through this, it can be seen that the MME 830 only needs to set a context for the UDSRB for the user terminal 810 and that it is not necessary to set a context for other DRBs.

When the MME 830 recognizes that the data transmission/reception service through the control plane is requested for the user terminal, it is determined whether the UDSRB can be used, that is, whether there is a valid context of the UDSRB for the user terminal. do (S843).

If it is determined that the UDSRB can be used for the user terminal and context setting for another DRB is unnecessary, the MME 830 may transmit a user terminal context installation request message to the base station 820. (Step S845). For example, the initial UE context setup request message may include only the context of the SRB and the UDSRB and may be transmitted. Alternatively, the MME 830 may transmit the message including information indicating that only SRB and UDSRB will be used for the user terminal. In addition, the MME 830 may include QoS information to be applied to the UDSRB, for example, relative resource allocation priority, etc. together with the information.

When the base station 820 needs to apply the UDSRB to the user terminal 810 , the base station 820 sets the UDSRB according to the user terminal context received from the MME 830 . Configuring the UDSRB includes generating LC (Logical Channel) information for the UDSRB. If the message received from the MME is missing context information of the DRB or includes information indicating that only UDSRB and SRB will be used, the base station does not configure DRB and configures SRB and UDSRB proceed only

When applying the UDSRB to the user terminal 810 , the base station 820 transmits information for setting the UDSRB to the user terminal 810 ( S847 ). In this case, the UDSRB information may be delivered through an RRC connection reconfiguration message, and more specifically, the SRB-ToAddMod field of the RadioResourceConfigDedicated IE of the RRC connection reconfiguration message may be used. At this time, the LC priority of the UDSRB may be specified in the LogicalChannelConfig field included in the SRB-ToAddMode. In this case, the priority of the UDSRB may be set to a lower priority than other SRBs, and also a high priority It may be set to a lower priority than the LC of a DRB that should have , for example, a DRB using QCI 1 or QCI 5. In addition, the base station 820 transmits the message including information on the SRB.

Upon receiving the UDSRB and SRB configuration information from the base station 810 , the user terminal 810 generates the UDSRB and SRB according to the configuration information. Thereafter, the SMS (or message) transmitted through the control plane may be transmitted using the UDSRB.

The base station 820 may transmit a message informing the MME 830 that the context installation for the user terminal has been completed (S849). For example, the base station 820 notifies the MME 830 that the context installation is complete through the Initial UE context setup complete message, which may include information indicating that only the UDSRB and the SRB have been configured.

The MME 830 may determine whether to perform a process for creating/renewing a GTP tunnel with the SGW based on the context installation complete message received from the base station. If only the UDSRB and the SRB are configured for the user terminal 810, the MME 830 does not perform a process for creating/renewing the SGW and the GTP tunnel (step S851). That is, the MME 830 does not perform the process of transmitting the Modify bearer request message.

Meanwhile, in the third embodiment of the present invention, the case of setting the UDSRB has been described. However, the embodiment of the present invention can be applied not only to the case of setting the UDSRB, but also to the case of using the SMS using the SRB2 as in the first embodiment. That is, it is possible to transmit and receive SMS or control plane using SRB2 without establishing a separate bearer UDSRB for transmitting user data through SMS or control plane. In this case, when it is determined that there is no need to set the DRB for general data transmission and reception by applying the above embodiment in the same way, only SRB2 and SRB may be configured. In this case, the DRB setting process may be omitted.

As mentioned above, SMS has a predetermined message transmission pattern (ie, SMS-ACK-Delivery Rerpot-ACK transmission and reception), so the user terminal and the network determine when and when all transactions are completed once SMS transmission is started. Able to know. If the SMS transmission transaction is completed, the RRC connection to the user terminal is released to prevent unnecessary battery consumption of the user terminal and waste of available resources of the base station. A fourth embodiment of the present invention will be described with reference to FIG. 9 below.

9 illustrates an operation of releasing an RRC connection when SMS transmission is completed according to an embodiment of the present invention.

The user terminal 910 and the network are in a state of transmitting only data transmission/reception through a control plane through the above-described embodiment (that is, a state in which only SRB and UDSRB are set without DRB setting) (S901).

If the user terminal determines that the SMS transaction is complete (S911), the user terminal may send an RRC connection release request to the base station (S913). In this case, the terminal 910 may additionally include information indicating that there is no activity for the user terminal or that data transmission has ended.

The MME may determine that the SMS processing is complete. If the MME 930 determines that the SMS transaction is complete (S921), the MME 930 may send a UE context release request to the base station 920 (S923). In this case, the MME 930 may additionally include information indicating that there is no activity for the user terminal 910 or that data transmission has ended.

The base station may recognize that the connection to the user terminal 910 may be released through at least one of the two processes (notification of the terminal or notification of the base station). Recognizing that the connection to the terminal may be released, the base station 920 may release the signaling connection to the user terminal 910 and all resources (S931). In addition, the base station may transmit a process for releasing the RRC connection to the user terminal, that is, an RRC connection release message to the user terminal.

Meanwhile, in the above embodiment, the request of the user terminal to release the RRC connection is described only when it is determined that the SMS transmission is completed, but in the above embodiment, the user terminal requests the RRC connection release in another situation, for example, general It may be applied even when the UE confirms that the data transmission/reception has been completed while setting and using the DRB for data transmission/reception.

Meanwhile, in the above embodiment, the user terminal's request for RRC connection release may be made using a UE assistant information message. In this message, the power configuration preferred by the user terminal may be set to lowPowerConsumption, information indicating that the user's activity has ended (endofuserActivity), RRC connection release request (RRCReleaseRequest), etc. may be set in this message. If the base station receives the UE assistant information message including the information from the user terminal, the base station may perform an operation for releasing the RRC connection of the user terminal.

In addition, the request message for releasing the RRC connection may be transmitted from the user terminal to the MME rather than the base station. In this case, the user terminal transmits, to the MME, a NAS message indicating that RRC connection release is required or information indicating that the activity of the user terminal is over. Upon receiving this, the MME may transmit a command to release the S1 or UE context to the base station.

10 is a block diagram illustrating a communication terminal according to an embodiment of the present invention.

Referring to FIG. 10 , the terminal 1000 may include a transceiver 1010 , a storage 1020 , and a controller 1030 . The transceiver 1010 may communicate with at least one network node. The storage unit 1020 may store information and various programs for driving the terminal 1000 . The controller 1030 may control the overall operation of the terminal 1000 . The controller 1030 may control the operation of the terminal according to the first to fourth embodiments of the present invention.

According to an embodiment of the present invention, the control unit 1030 is an attach request including user data signaling radio bearer (UDSRB) request information or a tracking area update (hereinafter, TAU). ) to transmit a request message, receive the UDSRB configuration information from the base station, generate a UDSRB based on the UDSRB configuration information, and receive user data through a control plane using the generated UDSRB. can be controlled In this case, the UDSRB may be a radio bearer for transmitting and receiving user data through a control plane.

Also, when generating the UDSRB, the controller 1030 may control to generate a logical channel between the terminal and the base station corresponding to the UDSRB. In addition, the control unit controls to receive the radio resource for the UDSRB from the base station to be scheduled, in this case, the UDSRB is another signaling radio bearer (SBR) or a preset range QCI (QoS Class Identifier) having a value A scheduling priority may be set lower than that of a data radio bearer (DRB).

In addition, the control unit 1030 determines whether there is data to be transmitted/received through the user plane, and if there is no data transmitted/received through the user plane, transmits an RRC connection request message for user data transmission/reception using the control plane, In response to the RRC connection request message, it is possible to control to omit configuration of a data radio bearer (DRB) when establishing a bearer.

In addition, the controller 1030 may determine whether the user data processing using the UDSRB is complete, and if it is determined that it is complete, transmit an RRC connection release message to the base station, and control to release the RRC connection with the base station. .

In the above description, the configuration and functions of the terminal 1000 are divided into blocks, but this is for convenience of description and is not intended to limit the scope of the present invention. In addition, the terminal 1000 may perform the operation of the terminal according to the embodiment of the present invention described with reference to FIGS. 2 to 9 as well as the operation described with reference to FIG. 10 .

In addition, the controller 1030 of the terminal may control the terminal to perform the operation of the terminal described in the embodiment described with reference to FIGS. 13 to 26 below.

11 is a block diagram illustrating a base station according to an embodiment of the present invention.

Referring to FIG. 11 , the base station 1100 may include a wired/wireless communication unit 1110 , a storage unit 1120 , and a control unit 1130 . The wired/wireless communication unit 1110 may communicate with at least one network node. The storage unit 1120 may store information and various programs for driving the base station 1100 . The controller 1130 may control the overall operation of the base station 1100 . The controller 1130 may control the operation of the base station according to the first to fourth embodiments of the present invention.

According to an embodiment of the present invention, the controller 1130 transmits an Attach request or Tracking Area Update (TAU) request message received from the terminal to a mobility management entity (hereinafter referred to as MME). and receives a terminal context setup message including information indicating whether user data signaling radio bearer (UDSRB) support for the terminal is supported from the MME, and based on the terminal context setup message A UDSRB may be configured in the terminal, and user data may be transmitted/received using the configured UDSRB. In this case, the UDSRB may be a radio bearer for transmitting and receiving user data through a control plane.

Also, when configuring the UDSRB, the controller 1130 may control to create a logical channel between the terminal and the base station corresponding to the UDSRB.

In addition, the control unit 1130 controls the radio resource scheduling for the UDSRB to the terminal, in this case, the UDSRB is another signaling radio bearer (SBR) or a QCI (QoS Class Identifier) value of a preset range. A scheduling priority may be set lower than that of a data radio bearer (DRB) having .

In the above description, the configuration and function of the base station 1100 are divided into blocks, but this is for convenience of description and is not intended to limit the scope of the present invention. In addition, the base station 1100 may perform the operation of the base station according to the embodiment of the present invention described with reference to FIGS. 2 to 9 as well as the operation described with reference to FIG. 11 .

In addition, the control unit 1130 of the base station may support the terminal to communicate with the upper node in the embodiments of FIGS. 13 to 26 below.

12 is a block diagram illustrating an MME according to an embodiment of the present invention.

Referring to FIG. 12 , the MME 1200 may include a communication unit 1210 , a storage unit 1220 , and a control unit 1230 . The communication unit 1210 may communicate with at least one network node. The storage unit 1220 may store information and various programs for driving the MME 1200 . The controller 1230 may control the overall operation of the MME 1230 . The controller 1230 may control the operation of the MME according to the first to fourth embodiments of the present invention.

According to an embodiment of the present invention, the controller 1230 receives an attach request or a tracking area update (hereinafter, TAU) request message from the terminal, and based on the request message, the subscriber information server ( Transmitting a location area update message to a home subscriber server (hereinafter referred to as HSS), receiving subscriber information including user data signaling radio bearer (UDSRB) support indication information of the terminal from the HSS, and the subscriber It is possible to control to determine whether to apply the UDSRB to the terminal based on the information. In this case, the UDSRB may be a radio bearer for transmitting and receiving user data through a control plane.

Also, the controller 1230 may control to determine whether to apply UDSRB to the terminal based on UDSRB request information included in the Attach or TAU request message and UDSRB support indication information in the subscriber information. Also, when it is determined that the UDSRB is applied, the controller 1230 may control to transmit a UE context configuration message including UDSRB support indication information to the base station.

In addition, the control unit 1230 determines whether there is data transmitted and received through the user plane for the terminal, and if there is no data transmitted and received through the user plane, data radio bearer (DRB) It can be controlled to transmit information indicating that setting is unnecessary.

In the above description, the configuration and function of the MME 1200 are divided into blocks, but this is for convenience of description and is not intended to limit the scope of the present invention. In addition, the MME 1200 may perform the operation of the MME according to the embodiment of the present invention described with reference to FIGS. 2 to 9 , 19 and 20 as well as the operation described with reference to FIG. 12 .

Although each embodiment of the present invention has been described with reference to the drawings, this is for convenience of description, and each embodiment may be performed independently and may operate as a combination of different embodiments.

On the other hand, in the present specification and drawings, an embodiment is disclosed on the basis that the GMSC and MSC of the operator network are included as a transmission path when transmitting an SMS, but this is only a general purpose for easily explaining the technical content of the present invention and helping the understanding of the present invention. It is used in the sense that it is not intended to limit the scope of the present invention. The transmission path of the SMS may include other network entities. If the T4/T5 interface is used, the transmission path of the receiving (MT) SMS is transmitted to the MTC-IWF through the SMS-SC/GMSC/IWMSC, and again This can be done by passing the MTC-IWF to the MME.

On the other hand, if a ^3rd party (or service provider) signs a contract with a business operator and provides services, various new services are possible. For example, a ^3rd party enters into a sponsorship contract with an operator, and instead of providing a service to the ^3rd party in the operator network, the ^3rd party pays the traffic transmission/reception fee for the service instead of the user. (Sponsored data or Sponsored charging) service is possible.

For example, if a shopping mall service provider enters into a contract with a telecommunication service provider and introduces a sponsored data service for online shopping, users can receive online shopping service without paying a separate communication fee. A shopping mall service provider can expect an increase in sales of a shopping business or an increase in secondary sales such as advertisements in an online shopping mall.

13 is a diagram illustrating a network structure for providing a sponsored data service.

The WIC (WebRTC IMS Client, 1315) is client software for receiving a specific communication service inside the terminal 1310. In some embodiments of the present invention, the WIC 1315 may be a client for receiving a Web real-time communication (WebRTC) service of 3GPP.

WWSF (WebRT Web Server Function, 1320) is a web server introduced by a service provider to provide a service. In some embodiments of the present invention, the WWSF 1320 may be a server for providing a WebRTC service. The WWSF 1320 may include a communication unit that communicates with other network nodes and a control unit that controls the overall operation of the WWSF. The control unit of the WWSF may control to perform the operation of the WWSF (web server) described in the embodiment described with reference to FIGS. 14 to 26 below.

An enhanced P-CSCF (eP-CSCF, 1330) is an improved proxy-call session control function (P-CSCF) to support interworking services with a ^3rd party service provider. In some embodiments of the present invention, the eP-CSCF 1330 may be an improved device to provide a WebRTC service. From a general point of view, an entity that performs additional operations for service provision including eP-CSCF is referred to as a Service Enabling Server (SES).

The SES 1330 may include a communication unit that communicates with other network nodes and a control unit that controls the overall operation of the SES. The control unit of the SES may control to perform the operation of the SES described in the embodiment described with reference to FIGS. 14 to 26 below.

The PCRF 1340 is an entity that collectively controls QoS and charging for traffic, and may collectively control QoS or charging for services provided by a service provider in an embodiment of the present invention. The PCRF may include a communication unit that communicates with other network nodes and a control unit that controls the overall operation of the PCRF. The controller of the PCRF may control to perform the operation of the PCRF described in the embodiment described with reference to FIGS. 14 to 26 below.

P-GW (1350, PCEF, policy and charging enforcement function) A policy to be applied in the PCRF 120, that is, a Policy and Charging Control (PCC) rule may be applied and executed. The P-GW may include a communication unit communicating with other network nodes and a control unit controlling the overall operation of the P-GW. The controller of the P-GW may control to perform the operation of the P-GW described in the embodiment described with reference to FIGS. 14 to 26 below.

Meanwhile, in the description of the drawings and the embodiments of the present invention to be described later, a network structure for providing 3GPP WebRTC service will be assumed for simplicity and clarity of explanation, but the main gist of the present invention is limited to WebRTC service It is not, and it can be applied to other types of web services as it is without major changes. In this case, the WIC 1315 inside the terminal 1310 is client software for general web service, the WWSF 1320 is a general web server, and the eP-CSCF 1330 supports interworking between the operator and the ^3rd party service provider. It can be configured as a network device for

In addition, in the following description of embodiments of the present invention, the UE 1310 may refer to the WIC 1315 inside the UE.

14 is a diagram illustrating a series of processes for providing a sponsored data service to a user according to an embodiment of the present invention.

The user terminal 1410 transmits a request message to the Web Server (WWSF, 1420) to receive the web service (S1401). This message may be a message using an HTTP GET or POST method, and may include a user identifier and a uniform resource identifier (URI) indicating a requested page or resource.

The user terminal 1410 and the web server 1420 may perform additional mutual message exchange. During this process, information for mutual authentication between the user terminal and the web may be exchanged (S1403).

The web server 1420 transmits information for providing a web service in the form of sponsored data to the user terminal 1410 (S1405). This message may be a message using the HTTP GET, POST, or PUT method, and this message includes an access token indicating that the user terminal is permitted to access the operator network and use the sponsored data service. In addition, the message may further include information that can identify the sponsor (sponsor identifier) and information that can identify the subject providing the application service (Application Service Provider identifier, hereinafter referred to as ASP ID). In addition, an identifier (PLMN ID) of the target communication service provider may be further included. In the above description, an example is given in which the access token is used in a separate form from other service-related information, but all service-related information may be included in the access token and used.

The access token is information configured according to the format already agreed upon between the service provider and the telecommunication service provider, and may be information issued by the telecommunication service provider and delivered to the service provider in advance. In particular, a part of the access token contains information indicating that the user terminal is permitted to use the sponsored data service, and additionally information indicating the characteristics of the sponsored data (maximum usage capacity, allowed time, service type, etc.) can

Access token is information used when determining that there is authority for a characteristic service or resource. It is encoded according to the rules promised between the web server and the operator network (SES in the present invention), and also prevents incorrect use or falsification. It should be used in a form in which security is maintained according to the rules promised between the two. For this, the following method can be used.

- The operator provides a set of access tokens that can be issued to users from the web server, and the web server uses the access tokens one by one from the set.

- The operator creates and verifies an access token with the same rules as the web server has mutually trusted authentication information (eg, pre shared key). For example, the web server uses at least one of the user's identifier, service provider ID (sponsor ID, application service provider ID), current time, PLMN ID, and other service-related information and a pre-shared key to obtain an access token. produce. The operator network (SES) checks whether the received access token is valid using the information and the pre-shared key.

The user terminal 1410 transmits a service request message to a service enabling server (SES or eP-CSCF, 1430) for service use through the operator network (S1407). This message can be encoded using the HTTP protocol or the SIP protocol. In particular, when using the SIP protocol, it may be a message using the Register method or Invite method. This request message includes the access token received in the above process. In addition, information for identifying a sponsor for the sponsored data service (sponsor identifier) and information for identifying a subject providing an application service (Application Service Provider identifier, hereinafter referred to as ASP ID) may be included. In addition, an identifier (PLMN ID) of the target communication service provider may be further included. In addition, other additional information (identifier, address, etc.) of the web service that the user should receive may be included.

The SES 1430 checks whether the user terminal can use the sponsored data through the information received from the user terminal (S1409). The SES 1430 may use all or part of the access token delivered by the user terminal 1410 during this process. Also, the SES 1430 may exchange information with the user terminal 1410 for additional authentication and security.

If the sponsored data service is available for the user terminal 1410, the SES 1430 transmits a policy setting request message for starting the sponsored data service to the PCRF 1440 (S1411). This message may use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, or Re-Auth request. This message may include information that can identify the sponsor for the sponsored data service (sponsor identifier), and information that can identify the subject that provides the application service (Application Service Provider identifier, hereinafter referred to as ASP ID). . In addition, an identifier (PLMN ID) of the target communication service provider may be further included.

In addition, a service descriptor capable of identifying a service data flow for an actual service is included. The service descriptor may include at least one of an IP address, a port, a domain name, an application ID, and a URI to be provided with a service. In addition, information indicating the characteristics of the sponsored data service (data usage, allowed time, billing method, etc.) may be included, and this information may be information obtained through all or part of the access token previously received from the terminal. Hereinafter, the service description and the service flow description are used interchangeably.

The PCRF 1440 generates a Policy and Charging Control (PCC) rule based on the information received from the SES 1430 or updates it if there is an already generated and used PCC rule (S1413). In particular, the newly created or updated PCC rule is characterized in that it includes information for sponsored data.

The PCRF 1440 transmits a message for delivering the generated or updated PCC rule to the PGW (PCEF, 1450) (S1415). This message may use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, or Re-Auth request. This message includes a charging key for separate charging for sponsored data. A charging key for a sponsored data service may be allocated to be shared with a specific sponsor and ASP (Application Service Provider), rather than allocated to each user. In addition, the message includes a service descriptor that can identify the SDF (Service Data Flow) to which the sponsored charging is applied. If a data service other than sponsored data is prohibited for the user terminal, a service descriptor may be configured such that the gate is closed for the SDF other than the SDF to which sponsored charging is applied.

The PGW (PCEF, 1450) starts charging and traffic control according to the received PCC rule (S1417). In particular, it is characterized in that, for sponsored data, charging for the sponsor is performed using a received charging key, not general charging. If the use of specific data is prohibited (eg, all data other than the sponsored data service is blocked), the PCEF 1450 may also perform traffic control according to the received gate status of the PCC rule. .

The PGW 1450 transmits a response message informing the PCRF 1440 that the requested PCC rule application has been successful (S1419). This message may use the Diameter protocol. This message can use one of commands such as AA response, Accounting response, Credit-Control response, or Re-Auth response.

The PCRF 1440 transmits a response message informing the SES 1430 that the policy application for the requested sponsored data service is successful ( S1421 ). This message may use the Diameter protocol. This message can use one of commands such as AA response, Accounting response, Credit-Control response, or Re-Auth response.

The SES 1430 transmits a message indicating that service registration is complete to the user terminal 1410 (S1423). This message can be encoded using the HTTP protocol or the SIP protocol. In particular, when using the SIP protocol, it may be a message using 200 OK. This message may then include information indicating that the sponsored data service is applied. In addition, information on the sponsored data service (maximum allowable data amount, allowable time, etc.) may be included.

Meanwhile, when the EPS bearer creation or modification is required due to the sponsored data service, the PGW 1450 may trigger a process for this (S1425). During this process, packet filters for the sponsored data service generated by the PGW 1450 may be installed in the user terminal. If the use of specific data is prohibited (for example, all data other than the sponsored data service is blocked), the user terminal 1410 is set to allow packet transmission and reception only for a specific IP flow (packet filter) characterized in that they are installed.

The user terminal 1410 may then use the web service in the sponsored data method. If information on the sponsored data service is received through the above step, it may be shown to the user (S1427).

Meanwhile, in the above embodiments and embodiments to be described later, the access token may include more specific information for a sponsored data service. For example, the access token may include information indicating the user's level. That is, when the user terminal has a certain service level (or priority) in the web service, a differentiated sponsored data service may be provided accordingly. To this end, the access token issued by the service provider to the user has a different value according to the service level, and when the user terminal 1410 receiving it transmits the access token to the operator network (SES, 1430), the SES 1430 can classify the user's class according to the access token. Accordingly, the characteristics of the sponsored data service (maximum allowable data amount, allowable time, or billing method) can be differentiated. More specifically, if the user terminal 1410 is above a certain level, the sponsored data service is applied up to 1 GB, and if the service level is below a certain level, the sponsored data service is applied up to 200 MB.

15 is a diagram illustrating an operation in a case in which a charging key is not used as a modification of the embodiment of FIG. 14 .

Steps S1501 to S1513 are the same as/similar to the operations of steps S1401 to S1413 of FIG. 14 , and thus a description thereof will be omitted.

In step S1515, the PCRF 1540 transmits a message for transferring the generated or updated PCC rule to the PGW (PCEF, 1550). This message can use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, or Re-Auth request. This message includes information that can identify a sponsor for sponsored data and information that can identify an ASP. In addition, the message includes a service descriptor that can identify the SDF (Service Data Flow) to which the sponsored charging is applied. If data services other than sponsored data are prohibited for the user terminal, the service descriptor may be configured such that the gate is closed for the SDF other than the SDF to which sponsored charging is applied.

The PGW (PCEF, 1550) starts charging and traffic control according to the received PCC rule (S1517). In particular, it is characterized in that, for sponsored data, charging for the sponsor and a specific service provider is performed using the received sponsor ID and ASP ID instead of general charging. If the use of specific data is prohibited (eg, all data other than the sponsored data service is blocked), the PCEF 1550 also performs traffic control according to the gate status of the received PCC rule.

Since the subsequent process is the same as/similar to that of FIG. 14 , a detailed description thereof will be omitted.

Meanwhile, in the embodiments according to FIGS. 14 and 15 , the user terminals 1410 and 1510 receive information from the web servers 1510 and 1520 and create a PCC policy for a sponsored data service for the corresponding web service. It was characterized by In particular, the SES ( 1430 , 1530 ) or PCRF ( 1440 , 1540 ) of the operator network must be able to identify an IP flow (or service data flow) that is a target of a sponsored data service. If the address or port of the server providing the web service is constant, it may be preset and used in the SES (1430, 1530) or the PCRF (1440, 1540) of the operator network, but the address or port of the server providing the service In the case of dynamic changes (CDN-Contents Delivery Network, cache, NAT, etc.), it becomes difficult to use preset information.

In order to solve the above problem, in one embodiment of the present invention, the server of the service provider transmits addresses (addresses and ports, etc.) to be used to provide subsequent services to the user terminal 1510, and the user The terminal transmits it back to the operator network. An embodiment of the present invention proposes a method for accurately distinguishing IP flows that are the target of a sponsored data service even when the address of a web service (and contents included therein) is dynamically changed through this. . Hereinafter, "address" is information indicating where specific traffic exists, and is used to include not only IP addresses, ports, and domain names, but also URIs.

16 is a diagram illustrating a method of additionally transmitting an address of a web service according to an embodiment of the present invention.

Steps S1601 to S1603 are the same as/similar to the operations of steps S1401 to S1403 of FIG. 14, and thus a description thereof will be omitted.

In step S1605, the web server 1620 transmits information for providing a web service in the form of sponsored data to the user terminal 1620 (S1605). This message may be a message using the HTTP GET, POST, or PUT method, and this message includes an access token indicating that the user terminal is permitted to access the operator network and use the sponsored data service. In addition, the message may include information that can identify the sponsor (sponsor identifier) and information that can identify the subject that provides the application service (Application Service Provider identifier, hereinafter referred to as ASP ID). In addition, an identifier (PLMN ID) of the target communication service provider may be further included. In the above description, an example is given in which the access token is used in a separate form from other service-related information, but both the sponsor and service-related information may be included and used in the access token.

The access token is information configured according to the format already agreed upon between the service provider and the telecommunication service provider, and may be information issued by the telecommunication service provider and delivered to the service provider in advance. In particular, a part of the access token contains information indicating that the user terminal is permitted to use the sponsored data service, and additionally information indicating the characteristics of the sponsored data (maximum usage capacity, allowed time, service type, etc.) can In particular, it is characterized in that the message includes an address (or a list of addresses) to which the user terminal needs to access in order to receive a service thereafter. For example, when a user needs to receive an image at URI 1 and a video at URI 2 to receive a service, it is characterized by including their addresses. Such address information is called a service flow descriptor. The service flow description may also be delivered as an information element separate from the access token, but in another embodiment, it may be delivered included in the access token.

Access token is information used when determining that there is authority for a characteristic service or resource. It is encoded according to the rules promised between the web server and the operator network (SES in the present invention), and also prevents incorrect use or falsification. It should be used in a form in which security is maintained according to the rules promised between the two. For this, the following method can be used.

- The operator provides a set of access tokens that can be issued to users from the web server, and the web server uses the access tokens one by one from the set.

- The operator creates and verifies an access token with the same rules as the web server has mutually trusted authentication information (eg, pre shared key). For example, the web server uses at least one of the user's identifier, service provider ID (sponsor ID, application service provider ID), current time, PLMN ID, and other service-related information and a pre-shared key to obtain an access token. produce. The operator network (SES) checks whether the received access token is valid using the information and the pre-shared key.

In step S1607, the user terminal 1610 transmits a service request message to the SES (or eP-CSCF, 1630) for service use through the operator network. This message can be encoded using the HTTP protocol or the SIP protocol. In particular, when using the SIP protocol, it may be a message using the Register method or Invite method. This request message includes the access token received in the above process. In addition, this request message includes information that can identify the sponsor for the sponsored data service (sponsor identifier) and information that can identify the subject that provides the application service (Application Service Provider identifier, hereinafter referred to as ASP ID). may be included. In addition, this request message may include other additional information (identifier, address, etc.) of the web service to be received by the user. In particular, it is characterized in that the message includes an address (or a list of addresses) to which the user terminal needs to access in order to receive a service thereafter. For example, when a user needs to receive an image at URI 1 and a video at URI 2 to receive a service, it is characterized by including their addresses. In addition, an identifier (PLMN ID) of the target communication service provider may be further included. In the above description, an example is given in which the access token is used in a separate form from other service-related information including the address for the service, but both the sponsor and service-related information may be included and encoded in the access token.

In step S1609 , the SES 1630 checks whether the user terminal 1610 can use the sponsored data through the information received from the user terminal 1610 . During this process, all or part of the access token delivered by the user terminal 1610 is used. Also, the SES 1630 may exchange information with the user terminal 1610 for additional authentication and security. In addition, the SES 1630 is a packet to be installed in a PCC rule or a user terminal based on a service flow descriptor received from the user terminal 1610, that is, a list of addresses to which the user terminal needs to access to receive a service thereafter. Information to configure the filters (packet filters) can be identified.

In step S1611 , if the sponsored data service is available for the user terminal 1610 , the SES 1630 transmits a policy setting request message for starting the sponsored data service to the PCRF 1640 . This message can use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, or Re-Auth request. This message may include information that can identify the sponsor for the sponsored data service (sponsor identifier), and information that can identify the subject that provides the application service (Application Service Provider identifier, hereinafter referred to as ASP ID). . In addition, a service descriptor capable of identifying a service data flow for an actual service is included.

The service descriptor may include at least one of an IP address, a port, a domain name, an application ID, and a URI to be provided with a service. In addition, information indicating the characteristics of the sponsored data service (data usage, allowed time, billing method, etc.) may be included, and this information may be information obtained through all or part of the access token previously received from the terminal 1610. . This message also includes a service flow descriptor received from the user terminal 1610, that is, a list of addresses to which the user terminal 1610 should connect to receive a service thereafter. This information is used to configure the target SDF when the PCRF 1640 generates or updates a PCC rule for a sponsored data service. The service flow description may also be delivered as an information element separate from the access token, but in another embodiment, it may be delivered included in the access token.

Since the subsequent steps are the same as/similar to the operations following step S1413 of FIG. 14 , a description thereof will be omitted.

Meanwhile, although the embodiment of FIG. 16 describes a case in which a charging key is used as in FIG. 14 for sponsored charging, it is not limited thereto, and charging is performed using the sponsor ID and ASP ID as in FIG. 15 . It can also be applied to the process. In this case, steps S1613 to S1617 of FIG. 16 may be changed to steps S1613 to S1617 of FIG. 15 .

Meanwhile, by extending the embodiments of the present invention, it is also possible to provide a conditional sponsored data service. That is, the sponsored data service is not always provided, but the sponsored data is provided only when a certain condition is satisfied. More specifically, for example, when a user uses an online shopping service, it is possible for the service provider to pay the data fee on behalf of the user only when the user actually purchases the item while withholding the billing with the sponsored data. . The above condition may be set in advance in a server that provides a sponsored data service.

17 is a diagram illustrating an operation for providing a conditional free charging service according to an embodiment of the present invention.

The user terminal 1710 , the web server 1720 , and the operator network finish exchanging information for receiving the sponsored data service by applying the embodiments of FIGS. 14 to 17 of the present invention. The difference of this embodiment is that the web service provider does not unconditionally pay the data fee when the sponsored data service starts and the sponsored billing is performed, but only when a specific condition is satisfied. Accordingly, the user terminal 1710 may display a screen providing information on the conditionally sponsored data service to the user.

The user terminal 1710 and the service provider server 1720 exchange messages for a service (S1703). During this process, the server 1720 of the service provider continues to check whether a condition for free data in the sponsored data service is satisfied (S1705). The condition includes an operation in which a transaction of purchasing a product in an online shopping mall is completed or a transaction of viewing a specific advertisement a certain number of times or more is completed.

If the condition for data free of charge is satisfied, the web server 1720 transmits information that the sponsored data can be processed free of charge to the user terminal 1710 ( S1707 ). This message may be a message using the HTTP GET, POST, or PUT method, and this message includes an access token indicating that the sponsored data service is free of charge. In addition, the message may include information that can identify the sponsor (sponsor identifier) and information that can identify the subject that provides the application service (Application Service Provider identifier, hereinafter referred to as ASP ID).

The access token is different from the first access token indicating that the use of sponsored data is allowed. can In particular, a part of the access token is characterized in that it contains information indicating that the user terminal is permitted to use the sponsored data service, and additionally includes information indicating that charging among the sponsored data services is free.

The user terminal 1710 transmits a service request message to the SES (or eP-CSCF, 1730) for service use through the operator network (S1709). This message can be encoded using the HTTP protocol or the SIP protocol. In particular, when using the SIP protocol, it may be a message using the Register method, Invite method, or Option method. This request message includes the access token received in the above process. In addition, information for identifying a sponsor for the sponsored data service (sponsor identifier) and information for identifying a subject providing an application service (Application Service Provider identifier, hereinafter referred to as ASP ID) may be included.

The SES 1730 checks whether the sponsored data can be freed by the user terminal 1710 through the information received from the user terminal 1710 ( S1711 ). During this process, all or part of the access token delivered by the user terminal 1710 is used. Also, the SES 1730 may exchange information with the user terminal 1710 for additional authentication and security.

If free use of the sponsored data is possible for the user terminal 1710, the SES 1730 transmits a request message informing the PCRF 1740 that charging for the sponsored data service is changed to free (S1713). This message may use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, Session Termination request, or Re-Auth request. This message may include information that can identify the sponsor for the sponsored data service (sponsor identifier), and information that can identify the subject that provides the application service (Application Service Provider identifier, hereinafter referred to as ASP ID). .

In addition, the message includes a service descriptor that can identify a service data flow for an actual service. The service descriptor may include at least one of an IP address, a port, a domain name, an application ID, and a URI to be provided with a service. In addition, information indicating the characteristics of the sponsored data service (data usage, allowed time, billing method, etc.) may be included, and this information may be information obtained through all or part of the access token previously received from the terminal. In addition, this message includes information indicating that the type of charging is free (no charging).

The PCRF 1740 generates a Policy and Charging Control (PCC) rule based on the information received from the SES 1730 or updates it if there is a previously generated and used PCC rule (S1715). In particular, the newly created or updated PCC rule is characterized in that it includes information indicating that charging is free.

The PCRF 1740 transmits a message for delivering the generated or updated PCC rule to the PGW (PCEF, 1750) (S1717). This message may use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, Session Termination request, or Re-Auth request. This message includes a charging key for separate charging for sponsored data. A charging key for the sponsored data service may be allocated to be shared with a specific sponsor and ASP, rather than allocated for each user. In addition, the message includes a service descriptor that can identify SDF (Service Data Flow) to which sponsored charging is applied.

If a data service other than sponsored data is prohibited for the user terminal 1710, a service descriptor may be configured such that the gate is closed for the SDF other than the SDF to which sponsored charging is applied. there is. In addition, this message includes information indicating that the type of charging is free (no charging).

The PGW (PCEF, 1750) starts charging and traffic control according to the received PCC rule (S1719). In particular, it is characterized in that, for sponsored data, charging for the sponsor is performed using a received charging key, not general charging. If the use of specific data is prohibited (eg, all data other than the sponsored data service is blocked), the PCEF 1750 also performs traffic control according to the gate status of the received PCC rule.

In addition, the PGW 1750 does not perform charging by determining that free (no charging) is applied to the sponsored data through the message received from the PCRF 1740, and also invalidates the charging information collected so far. there is. The PCEF 1750 may also exchange information with an Online Charging System (OCS) or an Offline Charging System (OFCS) to inform that charging should not be performed if necessary.

The PGW 1750 transmits a response message informing the PCRF 1740 that the requested PCC rule application has been successful (S1721). This message may use the Diameter protocol. This message can use one of commands such as AA response, Accounting response, Credit-Control response, or Re-Auth response. This message may include information indicating that a free charge applies.

The PCRF 1740 transmits a response message informing the SES 1730 that the policy application for the requested sponsored data service has succeeded (S1723). This message may use the Diameter protocol. This message can use one of commands such as AA response, Accounting response, Credit-Control response, or Re-Auth response. This message may include information indicating that a free charge applies.

The SES 1730 transmits a message informing the user terminal 1710 that free charging is applied to this message (S1725). This message can be encoded using the HTTP protocol or the SIP protocol. In particular, when using the SIP protocol, it may be a message using 200 OK.

The user terminal 1710 may use a web service using a free sponsored data method (S1727). In addition, a screen informing the user that a free sponsored data service is provided may be displayed.

On the other hand, if the embodiment of FIG. 17 is expanded, it is possible to expand not only the conditional sponsored data service but also change the characteristics of the sponsored data (maximum data amount, allowable time, etc.) according to the user's activity. For example, the initial sponsored data service is set to transmit and receive traffic of up to 1 GB. It adds 1 GB to the allowed amount. The above condition may be set in advance in a server that provides a sponsored data service.

18 is a diagram illustrating a process of changing a sponsored data service according to a user's activity.

The user terminal 1810 , the web server 1820 , and the operator network may finish exchanging information for receiving the sponsored data service in advance by applying the embodiments of FIGS. 14 to 17 of the present invention.

The user terminal 1810 and the service provider server 1820 exchange messages for a service (S1801). For example, making a purchase or continuing to request a web page that contains advertisements. During this process, the server 1820 of the service provider continues to check whether a condition for changing the characteristic (maximum data allowable or allowable time) of the sponsored data service is satisfied ( S1803 ). The condition includes completion of a transaction for purchasing a product in an online shopping mall, or completion of a transaction of viewing a specific advertisement a predetermined number of times or more.

If the condition for free data is satisfied, the web server 1820 transmits information for upgrading the sponsored data service to the user terminal 1810 (S1805). This message can be a message using HTTP GET, POST, or PUT method, and this message includes information for upgrading the sponsored data service and an access token. In addition, the message may include information that can identify the sponsor (sponsor identifier) and information that can identify the subject that provides the application service (Application Service Provider identifier, hereinafter referred to as ASP ID).

The access token is different from the first access token indicating that the use of sponsored data is allowed. can In particular, it is characterized in that it includes information indicating that it is permitted to upgrade the sponsored data service of the access token. That is, the access token may be in a form that contains the conditions of the upgraded sponsored data service (additional data amount or allowed time), or the access token contains only information indicating that the upgrade of the sponsored data service is permitted, and upgrade information (additional data amount or allowed time, billing type, etc.) may be transmitted as separate information.

The user terminal 1810 transmits a service request message to the SES (or eP-CSCF, 1830) for service use through the operator network. This message can be encoded using the HTTP protocol or the SIP protocol. In particular, when using the SIP protocol, it may be a message using the Register method, Invite method, or Option method. This request message includes the access token received in the above process. In addition, information for identifying a sponsor for the sponsored data service (sponsor identifier) and information for identifying a subject providing an application service (Application Service Provider identifier, hereinafter referred to as ASP ID) may be included. The access token may be in a form that contains the conditions of the upgraded sponsored data service (additional amount of data or allowed time), or the access token contains only information indicating that the upgrade to the sponsored data service is permitted, and includes upgrade information (additional The amount of data to be used, time allowed, billing type, etc.) may be transmitted as separate information.

The SES 1830 checks whether the user terminal can upgrade the sponsored data service through the information received from the user terminal 1810 (S1809). During this process, all or part of the access token delivered by the user terminal and information received from the user terminal are used. In addition, the SES 1830 may exchange information for additional authentication and security with the user terminal.

If the sponsored data service upgrade is possible for the user terminal 1810, the SES 1830 transmits a request message informing the PCRF 1840 that the upgrade for the sponsored data service is switched (S1811). This message may use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, Session Termination request, or Re-Auth request. This message may include information that can identify the sponsor for the sponsored data service (sponsor identifier), and information that can identify the subject that provides the application service (Application Service Provider identifier, hereinafter referred to as ASP ID). .

In addition, a service descriptor capable of identifying a service data flow for an actual service is included. The service descriptor may include at least one of an IP address, a port, a domain name, an application ID, and a URI to be provided with a service. In addition, information indicating the characteristics of the updated sponsored data service (data usage, allowed time, billing method, etc.) may be included, and this information may be information obtained through all or part of the access token previously received from the terminal.

The PCRF 1840 generates a Policy and Charging Control (PCC) rule based on the information received from the SES 1830 or updates it if there is a previously generated and used PCC rule (S1813). In particular, the newly created or updated PCC rule is characterized in that it includes information indicating the characteristics of the upgraded sponsored data service.

The PCRF 1840 transmits a message for delivering the generated or updated PCC rule to the PGW (PCEF, 1850) (S1815). This message may use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, Session Termination request, or Re-Auth request. This message includes a charging key for separate charging for sponsored data. The charging key for the sponsored data service is not allocated for each user, but may be allocated to be shared for a specific sponsor and ASP. In addition, the message includes a service descriptor that can identify the SDF (Service Data Flow) to which the sponsored charging is applied. If a data service other than sponsored data is prohibited for the user terminal, a service descriptor may be configured such that the gate is closed for the SDF other than the SDF to which sponsored charging is applied. This message contains information indicating the characteristics of the upgraded sponsored data service (such as maximum transfer amount or time allowed).

The PGW (PCEF, 1850) starts charging and traffic control according to the received PCC rule (S1817). In particular, it is characterized in that, for sponsored data, charging for the sponsor is performed using a received charging key, not general charging. If the use of specific data is prohibited (eg, all data other than the sponsored data service is blocked), the PCEF 1850 also performs traffic control according to the received gate status of the PCC rule.

The PGW 1850 transmits a response message informing the PCRF 1840 that the requested PCC rule application has been successful (S1819). This message may use the Diameter protocol. This message can use one of commands such as AA response, Accounting response, Credit-Control response, or Re-Auth response.

The PCRF 1840 transmits a response message informing the SES 1830 that the policy application for the requested sponsored data service is successful (S1821). This message may use the Diameter protocol. This message can use one of commands such as AA response, Accounting response, Credit-Control response, or Re-Auth response.

Meanwhile, regardless of the order of the steps, the PCRF 1840 exchanges a message with a subscription profile repository (SPR) to store the updated contents of the sponsored data service for the user terminal 1810 ( S1823). This is to enable the user terminal 1810 to continue to access and receive sponsored data services even when the user terminal 1810 is detached or deregistered from the operator network. During the process, a message using a Diameter protocol, for example, a profile update request and a profile request answer message may be used. The message may include updated sponsored data service information, more specifically, the maximum allowed data usage, the allowable usage time, and the amount of data used so far and usage time information.

The SES 1830 transmits a message informing the user terminal 1810 that the updated sponsored data service is applied to this message (S1825). This message can be encoded using the HTTP protocol or the SIP protocol. In particular, when using the SIP protocol, it may be a message using 200 OK.

The user terminal 1810 may use the web service in the sponsored data method according to the updated condition. In addition, a screen informing the user that the characteristic (maximum transmission amount or allowable time) of the sponsored data service has been changed may be displayed.

In the previous embodiments of the present specification, when the user terminal notifies the server (SES) of the operator network access information for the sponsored data service, the SES transmits the sponsored data service to the core network nodes (PCRF, PCEF) of the operator network A method of delivering information to be provided to a user terminal is presented. On the other hand, the embodiments of the present invention can be applied to a user terminal directly delivering to the core network nodes without going through a specific server with a slight modification.

19 is a diagram illustrating a method in which a user terminal transmits access information to a core network node using a PCO.

The user terminal 1910 transmits a request message to the web server (Web Server, 1920) to receive the web service (S1901). This message can be a message using the HTTP GET or POST method. In addition, the message may include an identifier of the user and a uniform resource identifier (URI) indicating the requested page or resource. It is characterized in that the message includes an identifier (PLMN ID) of a telecommunication operator selected by the user and registered.

The user terminal 1910 and the web server 1920 may perform additional mutual message exchange (S1903). During this process, information for mutual authentication between the user terminal 1910 and the web may be exchanged.

The web server 1920 transmits information for providing a web service in the form of sponsored data to the user terminal 1910 (S1905). This message can be a message using the HTTP GET, POST, or PUT method. In addition, this message includes an access token indicating that the user terminal is permitted to access the operator network and use the sponsored data service. In addition, in this message, the service flow description (used synonymously with the service description), information that can identify the sponsor (sponsor identifier), and information that can identify the subject providing the application service (Application Service Provider identifier, later) ASP ID) may be further included. In addition, an identifier (PLMN ID) of the target communication service provider may be further included. The service flow description is information based on an IP 5-tuple or an access address (domain name or URI). In addition, the access token may include an expiration time of the access token and a session expiration time. In the above description, an example has been given in which the access token is used in a form separated from other service-related information. However, all service-related information may be included and used in the access token. In addition, the message may include information for verifying or authenticating the validity of the access token. For example, the message may include a Message Authentication Code (MAC) for verifying the integrity of the access token.

The access token is information configured according to the format already agreed upon between the service provider and the telecommunication service provider, and may be information issued by the telecommunication service provider and delivered to the service provider in advance. In particular, a part of the access token contains information indicating that the user terminal is permitted to use the sponsored data service, and additionally information indicating the characteristics of the sponsored data (maximum usage capacity, allowed time, service type, etc.) can Access token is information used when determining that there is authority for a characteristic service or resource. It is encoded according to the rules promised between the web server and the operator network (SES in the present invention), and also prevents incorrect use or falsification. It should be used in a form in which security is maintained according to the rules promised between the two. For this, the following method can be used.

- The operator provides a set of access tokens that can be issued to users from the web server, and the web server uses the access tokens one by one from the set.

- The operator verifies and authenticates the integrity of the access token with the same rules as the web server has mutually trusted authentication information (eg, pre shared key). For example, the web server includes a service provider ID (at least one of a sponsor ID and an application service provider ID), the current time, a PLMN ID, a service flow description (eg, an IP 5-tuple or a list of domain names or URIs); A MAC that can generate an access token payload using at least one or more of the expiration time and other service-related information, and use a pre-shared key or certificate in this payload to prove the integrity of the access token. Message Authentication Code) is generated. In the operator network, MAC is generated using the received access token and pre-shared key, and the received information is verified by comparing it with the received MAC.

In the above description, the MAC for verifying the integrity of the access token is described as separate information, but the MAC may be configured in a form included as a part of the access token. More specifically, the access token may be in a form that includes not only information for providing sponsored data service (service flow description, sponsor ID, ASP ID, etc.) there is. That is, in this case, the access token must be generated using the rest except for the MAC.

The user terminal 1910 transmits a request message for requesting a resource for receiving a data service to the operator network (S1907). More specifically, the user terminal 1910 transmits a bearer resource allocation request or a bearer resource modification request message to the core network node. For example, the core network node may be the MME 1930 . Hereinafter, it is assumed that the core network node is an MME and described. In this message, the information received from the web server 1920 is included and transmitted, and it is characterized in that the information is included in the PCO (Protocol Configuration Option) of the message. That is, the user terminal puts the access token received from the server into the PCO and transmits it. If the access token and MAC are separated, the MAC is also put in the PCO and transmitted. The user terminal 1910 may also include a Traffic Flow Aggregate (TFA) composed of IP information for a sponsored data service in the message. This TFA is information generated from the service flow description received from the server. Even if the user terminal 1910 has a packet filter (ie, match all filter) capable of transmitting and receiving all service data flows or has an EPS bearer configured to perform an equivalent operation, the user terminal 1910 may generate and transmit the resource request message to receive a sponsored data service. If the information received from the web server 1920 includes a domain name or URI instead of IP address/port information (ie, IP 5-tuple) of servers to which the user terminal needs to access in order to receive a service in the future, the user terminal ( 1910) may transmit the TFA including the address of the web server to which the user terminal 1910 has accessed.

The MME 1930 starts a process for creating or modifying a bearer context according to a request message received from the user terminal 1910 with the core network nodes (S1909). That is, the MME (1930) generates a bearer resource command message and transmits it to the SGW. This message includes information included in the message received from the user terminal 1910, that is, a PCO and a service flow description. The service flow description is converted and included in the form of TAD (Traffic Aggregate Description). That is, the packet filters (information that can identify IP 5-tuple) included in the service flow description are included in the TAD, included in the message, and delivered to the SGW. Upon receiving the message, the SGW forwards the message to the PGW 1940 .

The PGW 1940 performs a process for creating or modifying an IP-CAN session using the received information with the PCRF 1950 (S1911). More specifically, the PGW 1940 transmits a message to the PCRF 1950 and performs an operation for receiving the PCC rule for the user terminal 1910 . This message may use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, or Re-Auth request. This message may include information for the sponsored data service, that is, an access token. If the access token and the MAC are separated, the request message is transmitted including the MAC as well. In addition, the message includes information describing the service flow to the user terminal (service flow description received by TAD, TFT information, or packet filter information). In addition, the message may further include an identifier (PLMN ID) of the target carrier. The service flow description may include at least one of an IP 5-tuple (IP address, port, etc. to be provided with a service), a domain name, an application ID, and a URI.

The PCRF 1950 generates a PCC rule for providing a sponsored data service based on information received from the PGW 1940 or updates an existing PCC rule (S1913). Prior to this, the PCRF 1950 determines whether the access token is valid among the information received from the PGW 1940 (S1913). More specifically, the PCRF 1950 uses at least one of a sponsor identifier and an ASP identifier included in the received information to confirm that the request of the access token and the user terminal 1910 is valid for the subject providing the sponsored data service. It finds security information for judgment, and uses it to determine the validity (or integrity) of the received access token and the request of the user terminal.

More specifically, PCRF (1950) finds stored security information (pre-shared key or certificate, etc.) using at least one of a sponsor identifier and an ASP identifier included in the access token, and uses this security information and access token to obtain MAC create Thereafter, the PCRF 1950 receives the received access token through a process of comparing it with the received MAC (included in the access token or received as a separate information element) and the sponsored data service request of the user terminal 1910 using the same. Validate.

At this time, the PCRF 1950 may exchange information with a server in charge of authentication for a separate access token (eg, AAA- Authentication Authorization Accounting server, etc.). More specifically, the PCRF 1950 transmits the received access token to the authentication server. If the MAC is received separately from the access token, the MAC is transmitted to the authentication server. The authentication server may perform the same operation as described above to determine whether the received access token is valid or not, and deliver the result back to the PCRF 1950 .

When the PCRF (1950) determines that the received access token and the request of the user terminal 1910 are valid, it generates a PCC (Policy and Charging Control) rule, or if there is an already generated and used PCC rule, it can be updated. there is. In particular, the newly created or updated PCC rule is characterized by including information for sponsored data, and for this purpose, a charging key used for a specific sponsor and ASP is used.

The PCRF 1950 transmits a message for delivering the generated or updated PCC rule to the PGW (PCEF, 1940) (S1915). This message may use the Diameter protocol. This message can take one of the following commands: AA answer, Accounting answer, Credit-Control answer, or Re-Auth answer. This message includes a charging key for separate charging for sponsored data. A charging key for a sponsored data service may be allocated to be shared with a specific sponsor and ASP (Application Service Provider), rather than allocated to each user.

In addition, this message includes information that can identify SDF (Service Data Flow) to which sponsored charging is applied. If a data service other than sponsored data is prohibited for the user terminal 1910, a service descriptor may be configured such that the gate is closed for the SDF other than the SDF to which sponsored charging is applied. there is.

If the PGW 1940 includes a domain name or URI list instead of IP address/port information in the service flow description (ie, included in the access token) received from the user terminal 1910 through the PCO, then the PGW ( 1940) inspects the DNS (Domain Name System) query request or response message transmitted from the user terminal 1910. If the requested domain name is a domain name or URI included in the service flow description When included in the list, the PGW 1940 uses the responded IP address information (IP address and additional port number if necessary) to packet filters that can classify sponsored traffic (ie, PCC rule for sponsored data service). SDF template) to be added. To this end, the PGW 1940 may transmit a request for adding packet filters or adding IP address information to a PCC rule for a sponsored data service to the PCRF 1950 without exchanging information with the PCRF 1950 .

The PGW (PCEF, 1940) starts charging and traffic control according to the received PCC rule (S1917). In particular, it is characterized in that, for sponsored data, charging for the sponsor is performed using a received charging key, not general charging. If the use of specific data is prohibited (eg, all data other than the sponsored data service is blocked), the PCEF 1950 may also perform traffic control according to the gate status of the received PCC rule. .

On the other hand, when the PGW 1940 needs to create or modify an EPS bearer due to the sponsored data service, it may trigger a process for this ( S1919 ). During this process, packet filters for the sponsored data service generated by the PGW 1940 may be installed in the user terminal 1910 . If the use of specific data is prohibited (for example, all data other than the sponsored data service is blocked), a packet filter configured to allow packet transmission and reception only for a specific IP flow even to the user terminal 1910 characterized in that they are installed.

The user terminal 1910 may then use the web service in the sponsored data method (S1921). If information on the sponsored data service is received through the above step, it may be shown to the user.

Meanwhile, in the above embodiments and embodiments to be described later, the access token may include more specific information for a sponsored data service. For example, the access token may include information indicating the user's level. That is, when the user terminal has a certain service level (or priority) in the web service, a differentiated sponsored data service may be provided accordingly. To this end, the access token issued by the service provider to the user has different values according to the service class, and the user terminal receiving it can transmit this access token to the operator network. The core network node (PGW) can classify the user's class according to the received access token. Accordingly, the characteristics of the sponsored data service (maximum allowable data amount, allowable time, or billing method) may be differentiated according to service class. More specifically, if the user terminal is above a certain level, the sponsored data service is applied up to 1 GB, and if the service level is below a certain level, the sponsored data service is applied up to 200 MB.

Meanwhile, in the embodiment of FIG. 19, the PGW transmits the access token received through the PCO to the PCRF, and the PCRF verifies and uses it. However, in another embodiment of the present invention, the access token received by the PGW is described. You can also create or update PCC rules by directly processing the token and transmitting only necessary information to the PCRF.

20 is a diagram illustrating another method in which a user terminal transmits access information to a core network node using a PCO.

The user terminal 2010 transmits a request message to the web server (Web Server, 2020) to receive the web service (S2001). This message may be a message using an HTTP GET or POST method, and may include a user identifier and a uniform resource identifier (URI) indicating a requested page or resource. It is characterized in that the message includes an identifier (PLMN ID) of a telecommunication operator selected by the user and registered.

The user terminal 2010 and the web server 2020 may perform additional mutual message exchange (S2003). During this process, information for mutual authentication between the user terminal 2010 and the web may be exchanged.

The web server 2020 delivers information for providing a web service in the form of sponsored data to the user terminal (S2005). This message can be a message using the HTTP GET, POST, or PUT method. In addition, this message includes an access token indicating that the user terminal is permitted to access the operator network and use the sponsored data service. In addition, in this message, the service flow description (used synonymously with the service description), information that can identify the sponsor (sponsor identifier), and information that can identify the subject providing the application service (Application Service Provider identifier, later) ASP ID) may be further included. In addition, an identifier (PLMN ID) of the target communication service provider may be further included. The service flow description is information based on an IP 5-tuple or an access address (domain name or URI). In addition, the access token may include an expiration time of the access token and a session expiration time. In the above description, an example in which the access token is used in a separate form from other service-related information has been described. However, all service-related information may be included in the access token and used. In addition, the message may include information for verifying or authenticating the validity of the access token. For example, the message may include a Message Authentication Code (MAC) for verifying the integrity of the access token.

The access token is information configured according to the format already agreed upon between the service provider and the telecommunication service provider, and may be information issued by the telecommunication service provider and delivered to the service provider in advance. In particular, a part of the access token contains information indicating that the user terminal is permitted to use the sponsored data service, and additionally information indicating the characteristics of the sponsored data (maximum usage capacity, allowed time, service type, etc.) can Access token is information used when determining that there is authority for a characteristic service or resource. It is encoded according to the rules promised between the web server and the operator network (SES in the present invention), and also prevents incorrect use or falsification. It should be used in a form in which security is maintained according to the rules promised between the two. For this, the following method can be used.

- The operator provides a set of access tokens that can be issued to users from the web server, and the web server uses the access tokens one by one from the set.

- The operator verifies and authenticates the integrity of the access token with the same rules as the web server has mutually trusted authentication information (eg, pre shared key). For example, the web server includes a service provider ID (at least one of a sponsor ID and an application service provider ID), the current time, a PLMN ID, a service flow description (eg, an IP 5-tuple or a list of domain names or URIs); A MAC that can generate an access token payload using at least one or more of the expiration time and other service-related information, and use a pre-shared key or certificate in this payload to prove the integrity of the access token. Message Authentication Code) is generated. In the operator network, MAC is generated using the received access token and pre-shared key, and the received information is verified by comparing it with the received MAC.

In the above description, the MAC for verifying the integrity of the access token is described as separate information, but the MAC may be configured in a form included as a part of the access token. More specifically, the access token may be in a form that includes not only information for providing sponsored data service (service flow description, sponsor ID, ASP ID, etc.) there is. That is, in this case, the access token must be generated using the rest except for the MAC.

The user terminal 2010 transmits a request message for requesting a resource for receiving a data service to the operator network (S2007). More specifically, the user terminal 2010 transmits a bearer resource allocation request or bearer resource modification request message to the core network node. For example, the core network node may be the MME 2030 . Hereinafter, it is assumed that the core network node is an MME. This message includes information received from the web server 2020 and is transmitted, and the information is characterized in that it is included in the PCO (Protocol Configuration Option) of the message. That is, the user terminal puts the access token received from the server into the PCO and transmits it. If the access token and MAC are separated, the MAC is also put in the PCO and transmitted. The user terminal 2010 may also include a Traffic Flow Aggregate (TFA) composed of IP information for a sponsored data service in the message. This TFA is information generated from the service flow description received from the server. Even if the user terminal 2010 has a packet filter (ie, match all filter) capable of transmitting and receiving all service data flows, or has an EPS bearer set to perform an equivalent operation, the user terminal 2010 may generate and transmit the resource request message to receive a sponsored data service. If the information received from the web server 2020 includes a domain name or URI instead of IP address/port information (ie, IP 5-tuple) of servers that the user terminal 2010 needs to access to receive a service in the future, The user terminal 2010 may transmit the TFA including the address of the web server the user terminal accessed.

The MME 2030 starts a process for creating or modifying a bearer context by the request message received from the user terminal 2010 with the core network nodes (S2009). That is, the MME 2030 generates a bearer resource command message and transmits it to the SGW. This message includes information included in the message received from the user terminal 2010, that is, a PCO and a service flow description. The service flow description is converted and included in the form of TAD (Traffic Aggregate Description). That is, the packet filters (information that can identify IP 5-tuple) included in the service flow description are included in the TAD, included in the message, and delivered to the SGW. Upon receiving the message, the SGW forwards the message to the PGW 2040 .

The PGW 2040 and the PCRF 2050 perform a process for creating or modifying an IP-CAN session using the received information. Prior to this, the PGW 2040 determines whether the access token among the received information is valid (S2011). More specifically, the PGW 2040 uses at least one of a sponsor identifier and an ASP identifier included in the received information to determine that the request of the access token and the user terminal 2010 is valid for the subject providing the sponsored data service. Find security information to make a decision. The PGW 2040 uses this to determine the validity (or integrity) of the received access token and the request of the user terminal 2010 .

More specifically, the PGW 2040 searches for stored security information (pre-shared key or certificate, etc.) using at least one of a sponsor identifier and an ASP identifier included in the access token, and uses this security information and the access token to obtain MAC After generating , the received access token and the sponsored data service request of the user terminal using the received access token through the process of comparison with the received MAC (included in the access token or received as a separate information element) are validated.

At this time, the PGW 2040 may exchange information with a server in charge of authentication for a separate access token (eg, AAA- Authentication Authorization Accounting server, etc.). More specifically, the PGW 2040 transmits the received access token to the server in charge of authentication. And if the MAC is received separately from the access token, the MAC is transmitted to the authentication server. The authentication server performs the same operation as described above to determine whether the received access token is valid or not, and transmits the result back to the PGW 2040 .

If the verification is successful, the PGW 2040 transmits a message to the PCRF 2050 and performs an operation for receiving the PCC rule for the user terminal 2010 (S2013). This message may use the Diameter protocol. This message can use one of the following commands: AA request, Accounting request, Credit-Control request, or Re-Auth request. This message may include information for the sponsored data service, that is, at least one of a sponsor identifier and an ASP identifier. In addition, the message includes information describing the service flow to the user terminal (service flow description received by TAD, TFT information, or packet filter information). In addition, the message may further include an identifier (PLMN ID) of the target carrier. The service flow description may include at least one of an IP 5-tuple (IP address, port, etc. to be provided with a service), a domain name, an application ID, and a URI.

The PCRF 2050 generates a PCC rule for providing a sponsored data service based on the information received from the PGW 2040 or updates an existing PCC rule (S2015). In particular, the newly created or updated PCC rule is characterized by including information for sponsored data, and for this purpose, a charging key used for a specific sponsor and ASP is used.

The PCRF 2050 transmits a message for delivering the generated or updated PCC rule to the PGW (PCEF, 2040) (S2017). This message may use the Diameter protocol. This message can take one of the following commands: AA answer, Accounting answer, Credit-Control answer, or Re-Auth answer. This message includes a charging key for separate charging for sponsored data. A charging key for a sponsored data service may be allocated to be shared with a specific sponsor and ASP (Application Service Provider), rather than allocated to each user.

In addition, this message includes information that can identify SDF (Service Data Flow) to which sponsored charging is applied. If a data service other than sponsored data is prohibited for the user terminal 2010, a service descriptor may be configured such that the gate is closed for the SDF other than the SDF to which sponsored charging is applied. there is.

If the PGW 2040 includes a domain name or URI list instead of IP address/port information in the service flow description (ie, included in the access token) received from the user terminal 2010 through the PCO, then the PGW ( The 2040 inspects a Domain Name System (DNS) query request or a response message transmitted from the user terminal 2010 (inspection). If the requested domain name is included in the domain name or URI list included in the service flow description, the PGW 2040 distinguishes the sponsored traffic by using the responded IP address information (IP address and additional port number if necessary). An operation is performed to add to possible packet filters (ie, SDF template of PCC rule for sponsored data service). To this end, the PGW 2040 may transmit a request for adding packet filters or adding IP address information to a PCC rule for a sponsored data service to the PCRF 2050 without exchanging information with the PCRF 2050 .

The PGW (PCEF, 2040) starts charging and traffic control according to the received PCC rule (S2019). In particular, it is characterized in that, for sponsored data, charging for the sponsor is performed using a received charging key, not general charging. If the use of specific data is prohibited (eg, all data other than the sponsored data service is blocked), the PCEF 2050 may also perform traffic control according to the received gate status of the PCC rule. .

On the other hand, when the EPS bearer creation or modification due to the sponsored data service is required, the PGW 2040 may trigger a process for this (S2021). During this process, packet filters for the sponsored data service generated by the PGW 2040 may be installed in the user terminal 2010 . If the use of specific data is prohibited (for example, all data other than the sponsored data service is blocked), a packet filter configured to allow packet transmission and reception only for a specific IP flow in the user terminal 2010 characterized in that they are installed.

The user terminal 2010 may then use the web service in the sponsored data method. If information on the sponsored data service is received through the above step, it may be shown to the user.

Meanwhile, in the above embodiments and embodiments to be described later, the access token may include more specific information for a sponsored data service. For example, the access token may include information indicating the user's level. That is, when the user terminal has a certain service level (or priority) in the web service, a differentiated sponsored data service may be provided accordingly. To this end, the access token issued by the service provider to the user has a different value according to the service level, and the user terminal receiving it can deliver the access token to the operator network. The core network node (PGW) can classify the user's class according to the received access token. Accordingly, the characteristics of the sponsored data service (maximum allowable data amount, allowable time, or billing method) may be differentiated according to service class. More specifically, if the user terminal is above a certain level, the sponsored data service is applied up to 1 GB, and if the service level is below a certain level, the sponsored data service is applied up to 200 MB.

Meanwhile, in this specification and FIGS. 14 to 20, the description was mainly focused on changing the billing of the sponsored data service according to the contract between the service provider and the telecommunication service provider and the user's activity, but this is only an easy explanation of the technical content of the present invention and is used in a general sense to help the understanding of the invention, and is not intended to limit the scope of the present invention. In the present invention, sponsored data and a policy for applying the sponsored data include not only charging but also traffic control, and the traffic control includes QoS (Quality of Service) control. That is, through embodiments of the present invention, a user can receive a sponsored data service, and the sponsored data service is not related to simply charging, but includes enabling the user to receive special QoS. For example, when a user receives a specific web service as a sponsored data service, it is possible to guarantee superior QoS to a service to which the sponsored data service is not applied or other users to which the sponsored data service is not applied.

Meanwhile, in the description of the above embodiments, it is exemplified that the access token and service and sponsor-related information (eg, sponsor ID, ASP ID, PLMN ID, and service flow descriptor, etc.) are transmitted as separate information elements. and sponsor-related information are all included in the access token, and it is also possible to be encoded and delivered.

Meanwhile, if the user receives the sponsored data service, it is necessary to provide the user with information about the sponsored data service. For example, the user may want to know the volume (volume) of data that he/she transmits/receives, which is processed as a sponsored data service and is not charged. If the sponsored data service is conditionally applied (for example, the total amount of data that can be transmitted and received free of charge due to the sponsored data service is limited or the time for which the sponsored data service is applied is limited), the user may want to know how much more sponsored data services they will receive. Hereinafter, various methods of notifying the amount of data processed by the sponsored data service will be described.

21 is a diagram for explaining a method of calculating the volume of data transmitted/received from a user terminal to a sponsored data service and notifying the user according to an embodiment of the present invention.

Referring to FIG. 21 , a user terminal receiving a sponsored data service receives an access token for a sponsored data service from a server or a network entity ( S2110 ). In the access token, the identifier of the sponsor providing the sponsored service (sponsor ID), the identifier indicating the service application (Application Service Provider ID), the address of the server providing the data service (IP 5 tuple or list of URLs), and the token are generated At least one of the date/time, random number value, key set identifier for identifying a key used for security, an algorithm identifier for identifying an algorithm used for security, and an authentication code (Message Authentication Code) may be included.

The user terminal can identify whether the traffic it transmits and receives based on the information included in the access token is the target of the sponsored data service. For example, the user terminal extracts identification information (eg, a specific APN, a specific IP 5 tuple, or the URL of a server, etc.) that can distinguish the IP flow, that is, the traffic that is the target of the sponsored data service from the received access token. do (S2120). The user terminal may store the extracted identification information. Based on the extracted information, the user terminal performs an operation of discriminating the target traffic of the sponsored data service (ie, non-billing) among the traffic it transmits and receives. That is, the user terminal may identify the target traffic of the sponsored data service by using the extracted identification information.

The user terminal transmits a service request message including the received access token to the operator network (S2130). In response, the user terminal obtains permission for the sponsored data service.

In the above description, it has been described that the user terminal obtains permission for the sponsored data service from the operator network after extracting identification information that can distinguish the traffic targeted for the sponsored data service from the access token. The order may or may not be reversed. In particular, when the user terminal cannot confirm whether the access token received from the server is legitimate, the user terminal transmits the access token to the operator's network, checks its validity, and obtains permission for the requested sponsored data service. The service information included in the token can be extracted, stored, and used.

The user terminal may transmit the user packet to the operator network or receive the user packet (S2140).

When a user plane data packet is transmitted/received, the user terminal performs an operation of determining whether it belongs to traffic that is a target of the previously stored sponsored data service (S2150). The user terminal may determine whether the user traffic is the target traffic of the sponsored data service by using the identification information extracted from the access token. The user terminal may determine whether the user traffic is traffic that is a target of the sponsored data service, based on whether information included in the user packet corresponds to the identification information. For example, the user terminal checks whether the PDN connection or EPS bearer context (eg, APN or QCI/ARP, etc.) to which the user packet belongs matches the previously extracted (or stored) identification information, so that the user traffic is sponsored data It can be determined whether the traffic is the target of the service. In addition, the user terminal may determine whether the user traffic is traffic targeted for the sponsored data service by checking whether all or part of the IP address/port or URL of the user packet matches the stored information.

If the transmitted/received user packet belongs to the sponsored data service traffic, the related user packet is managed as the sponsored data service traffic amount (S2160). For example, the user terminal may add the size of the transmitted/received packet to the amount of sponsored data. A method of managing the amount of sponsored data service traffic in the user terminal is not limited to a method of adding the amount of traffic, and various methods may be used. Although a description is omitted in this embodiment, the initial value of the amount of sponsored data may be initialized when the sponsored data service is started or may be set to a specific value. In addition, the traffic management may be periodically performed at a predetermined time point, or may be performed aperiodically at each time point when a user packet is generated.

The user terminal performs an operation to inform the user of the calculated sponsored data volume (the amount of sponsored data) as one piece of information about the sponsored data service (S2170). The user terminal may output information on the amount of sponsored data service traffic. This information may be expressed in the form of a graph or the data volume may be expressed as a number (eg, in bytes). The output information is not limited to information output through the screen of the user terminal, and various output means such as voice, vibration, and various sensors of the user terminal may be used.

22 is a diagram for explaining an operation of a user terminal when a sponsored data service is conditionally applied according to an embodiment of the present invention.

Referring to FIG. 22 , a user terminal receiving a sponsored data service receives an access token for a sponsored data service from a server or a network entity (S2210).

The user terminal can identify whether the traffic it transmits and receives based on the information included in the access token is the target of the sponsored data service. For example, the user terminal extracts identification information (eg, a specific APN, a specific IP 5 tuple, or the URL of a server, etc.) that can distinguish the IP flow, that is, the traffic that is the target of the sponsored data service from the received access token. do (S2220). The user terminal may store the extracted identification information. Based on the extracted identification information, the user terminal performs an operation of distinguishing traffic that is a target of the sponsored data service (ie, non-billing) among the traffic it transmits and receives. That is, the user terminal may identify the target traffic of the sponsored data service by using the extracted identification information. In addition, the user terminal extracts service restriction information (maximum volume/amount of data that can receive the sponsored data service) from the access token. In addition, the user terminal may store the extracted service restriction information.

The user terminal transmits a service request message including the received access token to the operator network (S2230). In response, the user terminal obtains permission for the sponsored data service.

In the above description, it was explained that the user terminal obtains permission for the sponsored data service from the operator network after extracting identification information and restriction information that can distinguish traffic targeted for the sponsored data service from the access token. The order of the two operations may be interchanged or changed. In particular, when the user terminal cannot confirm whether the access token received from the server is legitimate, the user terminal transmits the access token to the operator's network, checks its validity, and obtains permission for the requested sponsored data service. Sponsored data service information included in the token can be extracted, stored, and used.

The user terminal may transmit the user packet to the operator network or receive the user packet (S2240).

When a user plane data packet is transmitted/received, the user terminal performs an operation of determining whether it belongs to traffic that is a target of the previously stored sponsored data service (S2250). The user terminal may determine whether the user traffic is the target traffic of the sponsored data service by using the identification information extracted from the access token. The user terminal may determine whether the user traffic is traffic that is a target of the sponsored data service, based on whether information included in the user packet corresponds to the identification information. For example, the user terminal checks whether the PDN connection or EPS bearer context (eg, APN or QCI/ARP, etc.) to which the user packet belongs matches the previously extracted (or stored) identification information, and the user traffic is sponsored It can be determined whether the traffic is the target of the data service. In addition, the user terminal may determine whether the user traffic is traffic targeted for the sponsored data service by checking whether all or part of the IP address/port or URL of the user packet matches the stored information.

If the transmitted/received user packet belongs to the sponsored data service traffic, the related user packet is managed as the sponsored data service traffic amount (S2260). For dPfmf, the user terminal adds the size of the transmitted/received packet to the amount of sponsored data. Although a description is omitted in this embodiment, the initial value of the amount of sponsored data may be initialized when the sponsored data service is started or may be set to a specific value. A method of managing the amount of sponsored data service traffic in the user terminal is not limited to a method of adding the amount of traffic, and various methods may be used. When the total amount for the sponsored data service is limited, the user terminal may also calculate the remaining amount of sponsored data. This may be calculated by subtracting the sponsored data volume transmitted and received so far from the maximum sponsored data volume set in the previous process. The traffic management may be periodically performed at a predetermined time point, or may be performed aperiodically at each time point when a user packet is generated.

The user terminal performs an operation to inform the user of the calculated sponsored data volume (the amount of sponsored data) as one piece of information about the sponsored data service (S2270). The user terminal may output information on the amount of sponsored data service traffic. This information may be expressed in the form of a graph or the data volume may be expressed as a number (eg, in bytes). In addition, when the total amount of the sponsored data service is limited, the user terminal performs an operation to notify the user of the remaining sponsored data volume calculated in the previous process as information about the sponsored data service. . This information may be expressed in the form of a graph or the data volume may be expressed as a number (eg, in bytes).

23 is a diagram for describing an operation of a user terminal when a sponsored data service is conditionally applied according to an embodiment of the present invention.

Referring to FIG. 23 , a user terminal receiving a sponsored data service receives an access token for a sponsored data service from a server or a network entity (S2310).

The user terminal can identify whether the traffic it transmits and receives based on the information included in the access token is the target of the sponsored data service. For example, the user terminal extracts information (eg, a specific APN, a specific IP 5 tuple, or the URL of a server, etc.) that can distinguish the IP flow, that is, the target traffic of the sponsored data service from the received access token. (S2320). The user terminal may store the extracted identification information. Based on the extracted identification information, the user terminal performs an operation of distinguishing traffic that is a target of the sponsored data service (ie, non-billing) among the traffic it transmits and receives. That is, the user terminal may identify the target traffic of the sponsored data service by using the extracted identification information. In addition, the user terminal extracts service restriction information (the maximum time to receive the sponsored data service) from the access token. In addition, the user terminal may store the extracted service restriction information.

The user terminal transmits a service request message including the received access token to the operator network (S2330). In response, the user terminal obtains permission for the sponsored data service. The user terminal also starts a timer for recording the time the user receives the sponsored data service.

In the above description, it was explained that the user terminal obtains permission for the sponsored data service from the operator network after extracting identification information and restriction information that can distinguish traffic targeted for the sponsored data service from the access token. The order of the two operations may be interchanged or changed. In particular, when the user terminal cannot confirm whether the access token received from the server is legitimate, the user terminal transmits the access token to the operator's network, checks its validity, and obtains permission for the requested sponsored data service. Sponsored data service information included in the token can be extracted, stored, and used, and the timer can also be started during this process.

The user terminal then checks whether the timer expires (S2340).

If the timer expires, the user terminal performs an operation to notify the user that the sponsored data service has been terminated due to the time expiration ( S2350 ).

Also, the user terminal may selectively transmit a request message for terminating the sponsored data service service to the operator network (S2360). In addition, a response message indicating that the sponsored data service has been terminated may be received from the operator network.

Meanwhile, if the timer has not expired, the user terminal performs an operation to notify the user of information indicating the remaining time for the sponsored data service ( S2370 ). This information may be expressed in the form of a graph or may consist of expressing the remaining time as a number (eg, in hours, minutes, and seconds).

Meanwhile, in the embodiments of FIGS. 21 to 23, a method of extracting and using sponsored service information (information for classifying traffic, maximum volume, allowable time, etc.) included in the access token received from the server by the user terminal is proposed. did. The embodiment of the present invention is not limited thereto, and the user terminal may receive and use information for a sponsored data service (information for classifying traffic, maximum volume, allowable time, etc.) from an operator network instead of an access token.

24 is a diagram illustrating a method for a user terminal to receive and use information on a sponsored data service from an operator network.

Referring to FIG. 24 , a user terminal receiving a sponsored data service receives an access token for a sponsored data service from a server or a network entity ( S2410 ).

The user terminal transmits a service request message including the received access token to the operator network (S2420).

In response to this, the user terminal receives a message indicating obtaining permission for the sponsored data service from the operator network (S2430). In this message, information on the sponsored data service (information used in FIGS. 21 to 23 in the previous embodiment, more specifically information for classifying sponsored data traffic, the maximum allowable data volume of sponsored data, sponsored data information on at least one of the service application time, etc.) is included.

The user terminal stores the received information, and performs the remaining operations of FIGS. 21 to 23 in the previous embodiment (identifying the amount of sponsored traffic data by classifying sponsored data traffic, or notifying the user of information through a limited time/volume) or an operation to request termination from the network). The user terminal may perform operations S2150 and lower in FIG. 21 based on the received sponsored data service information (information for classifying sponsored data traffic). Based on the received sponsored data service information (allowed data volume information of sponsored data), the user terminal may perform operations S2250 and lower in FIG. 22 . In addition, the user terminal may perform operations S2340 and lower in FIG. 23 based on the received information on the sponsored data service (information on the application time of the sponsored data service).

On the other hand, the user terminal does not directly calculate or measure the information of the sponsored data service (such as the volume of sponsored data traffic transmitted and received so far, the remaining volume or time, etc.), and may request the operator network and use the received response information. there is. The user terminal may receive a response message to the sponsored data service information request message. Based on the information included in the response message, the user terminal may output at least one of transmitted and received sponsored data traffic volume information, available sponsored data traffic volume information, and sponsored data service application time information.

25 is a diagram illustrating a method for a user terminal to receive and use real-time information on a sponsored data service from a network.

Referring to FIG. 25 , the user terminal 2510 sends an information request message to find out the current state of the sponsored data service (volume of sponsored data transmitted and received by the user, remaining data volume, remaining time, etc.) It is transmitted to the operator network (S2501). The user terminal may request at least one of transmitted and received sponsored data traffic volume information, available sponsored data traffic volume information, and sponsored data service application time information by using the information request message. The recipient of this request message is an application function (AF) 2520 of the operator network, and more specifically, an enhanced proxy-call session control function (eP-CSCF) or a service enabling server (SES).

In addition, the user terminal 2510 generates and transmits the request message when the user performs an operation for checking the status information on the sponsored data service (that is, for checking the sponsored data service in the user terminal) It can be triggered by running an application, pressing a button/icon, or performing an action for status update). Alternatively, it may be performed automatically at every time interval preset in the user terminal 2510 .

The message may be encoded using the HTTP protocol. In particular, the message is characterized in that it includes information indicating that the AF 2530 of the operator network performs an operation for responding to the sponsored data service to the user terminal 2510 . In particular, the information may be encoded using a SOAP protocol. In addition, the message includes an identifier that can identify the user terminal 2510 or the user, an identifier that can identify the sponsored data service or a request identifier obtained when the sponsored data service is initially requested (request ID), and requested information. Information indicating the form of (the volume of sponsored data transmitted and received so far, sponsored fees so far, remaining volume, remaining time, etc.) may be included. The sponsored fee so far indicates the fee saved by the user by being paid by the sponsor ( ^3rd party, etc.) instead of the user through the sponsored data service.

Upon receiving the request message, the AF 2530 of the operator network searches for sponsored data service information (context) of the user terminal 2510 using at least one of an identifier, a service identifier, and a request identifier of the user or user terminal (S2503). ).

The AF 2530 transmits a response message to the user terminal 2510 (S2505). This message can be encoded using the HTTP protocol. In particular, it is characterized in that information indicating that the AF 2530 of the operator network performs an operation of providing the sponsored data service information according to the request of the user terminal 2510 is included. In particular, the information may be encoded using a SOAP protocol. In addition, the message includes an identifier for identifying the sponsored data service received previously or a request identifier (request ID) obtained when the sponsored data service is requested for the first time, and requested information (volume of sponsored data transmitted and received so far, the sponsor charged charges, remaining volume, remaining time, etc.) may be included.

The user terminal 2510 updates the information of the sponsored data service for the user using the received message (S2507). Also, the user terminal may perform an operation for notifying the user of updated information. This action displays a pop-up on the screen to notify the user of the current status of the sponsored data service (volume of sponsored data sent and received so far, sponsored rates up to direct payment, remaining volume, remaining time, etc.) or updating all or part of the screen of the user terminal that informs the status of the sponsored data service.

Meanwhile, in the above description, the AF 2530 transmits a response message in step S2503 based on the request message transmitted by the user terminal 2510 in step S2501. However, when a preset condition is satisfied in the AF 2530, automatically It can be set to transmit information on a sponsored data service to the user terminal 2510 . For example, period information, volume information of transmitted/received sponsored data service, sponsored rate information, remaining volume information of sponsored data service, and remaining volume information of sponsored data service are information about sponsored data service It may be set as a trigger condition for transmission. The AF 2530 may transmit information on the sponsored data service to the user terminal 2510 when a preset trigger condition is satisfied regardless of a request from the user terminal 2510 . In this case, the trigger condition may be set by a network operator in the AF 2530 or may be set according to a trigger condition setting request received from the user terminal 2510 .

Meanwhile, when an application capable of one or more sponsored data services is set or installed in the user terminal, the user terminal may apply a configuration for notifying the user of the characteristics of each sponsored data service.

26 is a diagram illustrating characteristics of sponsored data service applications by a user terminal according to an embodiment of the present invention.

Referring to FIG. 26 , the user terminal may include an output unit. The output unit may include various output means such as a screen output unit, a sound source output unit, and a vibration output unit. The output unit may be used to output sponsored data service related information. For example, the output unit may be the screen 2600 of the user terminal. The screen output unit of the user terminal may collect and show sponsored data service applications (applications, apps). The screen output unit 2600 may display a separate application, widget, or function showing information of the sponsored data service application.

Information indicating each sponsored service application may be displayed on the screen output unit 2600 . At least one sponsored data service related application 2610 , 2620 , 2630 , and 2640 may be displayed on the screen output unit 2600 . The application (application, app) may be expressed as text, image, or icon. The sponsored service applications, which are pre-loaded in the user terminal, may be already installed at the time of purchase of the user terminal, which is not purchased or selectively downloaded by the user.

Meanwhile, a plurality of applications may be displayed on the screen output unit 2600 of the user terminal. According to an embodiment of the present invention, the user terminal may display a sponsored data service related application among a plurality of applications to be distinguished from a general application. For example, an identifier for identifying the sponsored service related application may be displayed. A text image or an icon may be used as the identifier. In addition, the transparency or size of the sponsored data service related application may be set differently so that it can be distinguished from the general application. In addition, the sponsored data service related application may be set to be displayed in a designated separate location. The designated separate location may be a preset location of the screen output unit or a preset folder path. Information for distinguishing a sponsored data service-related application from a general application may be set by a user device, or may be determined from a network operator supporting the sponsored service. In addition, the sponsored data service related application and the general application may be distinguished by using identification information indicating the characteristics of the sponsored data service application mentioned below. A network entity supporting the sponsored data service may transmit identifier-related information so that the user terminal may display the identifier. The user terminal may display the identifier based on the identifier-related information received from the network entity as well as the user terminal's own setting.

Also, identification information 2613 , 2623 , 2633 , and 2643 indicating characteristics of each of the sponsored service applications may be displayed on the screen output unit 2600 . The identification information indicating the application characteristic may be always displayed on the screen output unit 2600 or may be additionally displayed according to a user's input. If it is additionally displayed according to a user's input, it may be displayed only for a preset period and then disappear. The characteristics of the sponsored service application may include the popularity of the sponsored data service or the user's current rating in the corresponding sponsored data service. According to application characteristics, information for identifying the popularity or rating of the sponsored service may be displayed. For example, identification information such as different colors, images, icons, and texts may be used. When different colors are used, different colors may be displayed according to the popularity or grade of the sponsored data service application. For example, different colors can be displayed according to popularity or rating, such as gold when the popularity is the highest, and silver after that. Alternatively, a separate image or icon text that can identify popularity or rating may be displayed. For example, if the popularity is high, the first place mark and the second place mark may be displayed as identification information. On the other hand, the sorting method may be used without separately displaying identification information for the sponsored data service application. For example, when the sponsored data service related application is displayed on the screen output unit 2600, it may be set to be sorted according to popularity or rating. The sorting may be performed in the user terminal at every preset period, or may be arranged aperiodically when there is a request for sorting in the user terminal. The user terminal may transmit a message requesting the identification information to a network entity supporting a sponsored data service. The network entity receiving the identification information request message may transmit a response message including the identification information to the user terminal. Based on the identification information received from the network entity, the terminal may display identification information such as color, icon, image, text, etc. for the characteristics of the sponsored data service application or perform sorting.

Meanwhile, each sponsored data service application may have state information 2615 , 2625 , 2635 , and 2645 . The status information may be information indicating a current service status for a user. As described in the previous embodiments, the service state may include at least one of information such as the volume of sponsored data transmitted and received so far, the sponsored fee so far, the remaining volume, and the remaining time. In addition, the status information may include a level obtained by the user from the corresponding sponsored service, service level/class information, and the like. These information may be expressed in numbers/text form, in graph form, or may be composed of pictures or icons representing each information. The status information may be always displayed on the screen output unit 2600 or additionally displayed according to a user's input. When the status information is additionally displayed according to a user input, it may disappear after being displayed only for a preset period. Also, the status information may be enlarged and displayed according to a user's input. For example, when at least one of a plurality of sponsored data service applications is selected, status information corresponding to the selected application may be enlarged and displayed, and when displayed together with a plurality of applications, details that could not be displayed due to space limitations Additional information may be displayed. Meanwhile, the status information may not only display current status information on the sponsored data service used by the user terminal, but also provide statistical information on usage up to now. In order for the user terminal to display the status information as described above, the status information may be provided from a sponsored data service network entity.

In the description of the above embodiments, it is basically assumed that the access token is transmitted from the server (web server or WWSF, etc.) to the user terminal, but this may be replaced by the user terminal directly generating the access token. That is, in the embodiments of the present invention, the process of the user terminal receiving the access token from the server is replaced with acquiring information (components of the access token described above) for generating the access token, and after that process, the user The terminal directly generates an access token and transmits it to the operator's network to receive sponsored data service.

On the other hand, in the present specification and drawings, preferred embodiments of the present invention have been disclosed, and although specific terms are used, these are only used in a general sense to easily explain the technical content of the present invention and to help the understanding of the present invention, It is not intended to limit the scope of the invention. In addition to the embodiments disclosed herein, it is apparent to those of ordinary skill in the art that other modifications based on the technical spirit of the present invention can be implemented.

Also, in the above-described embodiments, all steps may be selectively performed or omitted. Also, the steps in each embodiment do not necessarily occur in order and may be reversed. On the other hand, the embodiments of the present specification disclosed in the present specification and drawings are merely provided as specific examples to easily explain the technical content 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 is apparent to those of ordinary skill in the art to which this specification belongs that other modifications may be made based on the technical spirit of the present specification.

Claims (30)

In the terminal of a wireless communication system,
transceiver; and
An authentication procedure for a service provided by a service provider contracted with a network operator is performed with the first server, an access token for the service is obtained from the first server, and an enabler server is performed through the transceiver. ) to transmit a request message including the access token including an authentication code for verification of the access token, and to receive a response message including information related to an authorized service from the enabler server through the transceiver, , Based on QoS (quality of service) information, comprising a control unit for controlling to receive the data for the permitted service,
The QoS information is provided from the enabler server to the core network entity of the network operator. delete According to claim 1,
the access token is provided from the network operator to the service provider;
The access token is used to identify whether the service is allowed. According to claim 1,
The control unit is
Set a packet filter for the service, and control to identify packet transmission and reception capacity for the service based on the packet filter. 5. The method of claim 4,
The control unit is
The terminal, characterized in that the control to display information related to the service based on the packet transmission and reception capacity for the service. 6. The method of claim 5,
Information related to the above service,
remaining capacity for the service determined based on the allowed capacity for the service and packet transmission and reception capacity for the service; or
A terminal comprising at least one of information on the remaining time determined based on the allowed time. According to claim 1,
The service is
It is a specific service in which the service provider pays the network operator a fee for traffic between the terminal and the enabler server based on charging information provided to the core network entity from the enabler server. . In the enabler server of a wireless communication system,
transceiver; and
A request message including an access token including an authentication code for verification of the access token from a terminal through the transceiver and obtaining an access token for a service provided by a service provider having a contract with a network operator from the first server and a control unit that determines whether the terminal is authorized to use the service based on the access token, and controls to transmit a response message including information related to the permitted service to the terminal through the transceiver and ,
Data for the permitted service is provided based on QoS (quality of service) information,
The enabler server, characterized in that the QoS information is provided to the core network entity of the network operator from the enabler server. delete 9. The method of claim 8,
The service is a specific service in which the service provider pays the network operator a fee for traffic between the terminal and the enabler server based on charging information provided to the core network entity from the enabler server. An enabler server with A method performed by a terminal of a wireless communication system, comprising:
performing an authentication procedure for a service provided by a service provider contracted with a network operator with a first server;
obtaining an access token for the service from the first server;
transmitting a request message including the access token including an authentication code for verification of the access token to an enabler server;
receiving a response message including information related to an authorized service from the enabler server; and
Receiving data for the permitted service based on QoS (quality of service) information,
The method of claim 1, wherein the QoS information is provided from the enabler server to a core network entity of the network operator. delete 12. The method of claim 11,
the access token is provided from the network operator to the service provider;
The method of claim 1, wherein the access token is used to identify whether the service is allowed. 12. The method of claim 11,
setting a packet filter for the service;
and identifying packet transmission and reception capacity for the service based on the packet filter. 15. The method of claim 14,
The method further comprising the step of displaying information related to the service based on the packet transmission and reception capacity for the service. 16. The method of claim 15,
Information related to the above service,
remaining capacity for the service determined based on the allowed capacity for the service and packet transmission and reception capacity for the service; or
Method comprising at least one of information about the remaining time determined based on the allowed time. 12. The method of claim 11,
The service is
It is a specific service in which the service provider pays the network operator a fee for traffic between the terminal and the enabler server based on charging information provided from the enabler server to the core network entity. . A method performed by an enabler server of a wireless communication system, the method comprising:
obtaining, from a first server, an access token for a service provided by a service provider having a contract with a network operator;
receiving a request message including the access token including an authentication code for verification of the access token from a terminal;
determining whether the terminal is authorized to use the service based on the access token; and
Transmitting a response message including information related to the permitted service to the terminal,
Data for the permitted service is provided based on QoS (quality of service) information,
The method of claim 1, wherein the QoS information is provided from the enabler server to a core network entity of the network operator. delete 19. The method of claim 18,
The service is a specific service in which the service provider pays the network operator a fee for traffic between the terminal and the enabler server based on charging information provided to the core network entity from the enabler server. how to do it with delete delete delete delete delete delete delete delete delete delete

Images