WO2013085314A1 - Ims 기반의 이동통신 네트워크에서 스폰서 서비스 제공 방법 및 시스템 - Google Patents

Ims 기반의 이동통신 네트워크에서 스폰서 서비스 제공 방법 및 시스템 Download PDF

Info

Publication number
WO2013085314A1
WO2013085314A1 PCT/KR2012/010566 KR2012010566W WO2013085314A1 WO 2013085314 A1 WO2013085314 A1 WO 2013085314A1 KR 2012010566 W KR2012010566 W KR 2012010566W WO 2013085314 A1 WO2013085314 A1 WO 2013085314A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
server
sponsored
sponsored service
ssc
Prior art date
Application number
PCT/KR2012/010566
Other languages
English (en)
French (fr)
Inventor
이지철
이성원
배범식
임한나
정상수
조성연
최성호
Original Assignee
삼성전자 주식회사
경희대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사, 경희대학교 산학협력단 filed Critical 삼성전자 주식회사
Priority to US14/363,772 priority Critical patent/US10033878B2/en
Publication of WO2013085314A1 publication Critical patent/WO2013085314A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/57—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for integrated multimedia messaging subsystem [IMS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1471—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network splitting of costs
    • H04L12/1475—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network splitting of costs the splitting involving a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1482—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network involving use of telephony infrastructure for billing for the transport of data, e.g. call detail record [CDR] or intelligent network infrastructure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0192—Sponsored, subsidised calls via advertising, e.g. calling cards with ads or connecting to special ads, free calling time by purchasing goods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor

Definitions

  • the present invention relates to a method and system for providing a sponsored service (Internet Service Provider Server) that can pay the mobile communication fee of the terminal in an IMS-based mobile communication network.
  • a sponsored service Internet Service Provider Server
  • a mobile communication network provider provides an IP-based multimedia service through an IP Multimedia Subsystem (hereinafter, referred to as an IMS) core network.
  • IMS IP Multimedia Subsystem
  • the Internet service of the external 3rd party internet service provider is provided to the wireless terminal subscriber through the general IP network of the mobile communication network provider, and the IMS core network does nothing.
  • the Internet service concept in the conventional mobile communication network is shown in FIG.
  • the Internet service provider when the Internet service of the 3rd party Internet service provider is provided to the wireless terminal subscriber, the Internet service provider returns the profit obtained from the wireless terminal subscriber through advertising revenue to the corresponding wireless terminal subscriber.
  • the Internet service provider As a means for giving, there is a problem in that there is no method that can provide the cost of using the mobile communication network for the Internet service of the Internet service provider used by the corresponding wireless terminal subscriber.
  • an object of the present invention is to provide an IMS-based mobile communication network system for a sponsored service in which a 3rd party Internet service provider pays for the use of a mobile communication subscriber's mobile communication network.
  • the present invention can provide a differentiated service quality when provided by the sponsored service, the service quality can be dynamically controlled at the start of the Internet service, and is appropriately allowed at the start of the sponsored service It is an object of the present invention to provide an IMS-based mobile communication network system for a sponsored service that supports blocking of work in advance if it is not suitable by checking whether it is a service.
  • An object of the present invention is to provide an IMS-based mobile communication network system for a sponsored service that moves to a network and provides a corresponding service at a place closest to a wireless terminal.
  • a method of providing a sponsored service Internet Service Provider Server) that can pay for the mobile communication fee of the terminal (Sponsored Service) Transmitting a sponsored service initiation request message to a sponsored service server for providing the sponsored service by a sponsored service and connectivity client included in the terminal to provide the sponsored service; ; Determining, by the sponsor service server, whether the sponsored service is valid after receiving the start request message; If the sponsored service server determines that the sponsored service is valid, transmitting a sponsored service start approval message to the sponsored service client; Creating a sponsored service session between the sponsored service client and the internet service providing server; Generating, by the sponsor service server, billing information and transmitting the billing information to an AAA server (Authentication / Authorization / Accounting Sever) when the sponsor service client requests termination of the sponsored service; And terminating the sponsored service session.
  • an AAA server Authentication / Authorization / Accounting Sever
  • an Internet service provider server Internet Service Provider Server
  • Internet Service Provider Server Internet Service Provider Server
  • ponsored Service Sever Authentication / Authentication / Accounting Sever
  • AAA server Authentication / Authorization / Accounting Sever
  • the present invention it is possible to provide a sponsored service in which the 3rd party Internet service provider pays for the mobile terminal subscriber's mobile communication network.
  • the sponsored service When the sponsored service is provided, it can provide differentiated service quality, and the service quality can be dynamically controlled at the time when the Internet service starts.
  • the service quality can be dynamically controlled at the time when the Internet service starts.
  • whether or not the service is properly allowed may be checked to support blocking of the service in advance.
  • the service provider provides fast response time and wireless optimized service quality to wireless terminal subscribers who use internet service.
  • the service provider also temporarily uses the processing and communication capacity of mobile communication network providers in case of momentary load. As a result, it is possible to reduce the burden of additional expansion due to instant load, thereby providing satisfactory service to service users.
  • FIG. 1 is a diagram illustrating the concept of an Internet service in a mobile communication network according to the prior art.
  • FIG. 2 is a diagram illustrating the concept of an Internet service in a mobile communication network according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating a SSC server information acquisition process when accessing a mobile communication network according to an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an internal structure of a wireless terminal according to an embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating an approval procedure of an application sponsored service according to an embodiment of the present invention.
  • FIG. 6 is a flowchart illustrating a release procedure of an application sponsored service according to an embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating a procedure for rejecting an application sponsored service according to an embodiment of the present invention.
  • FIG. 8 is a flowchart illustrating a procedure for rejecting an application sponsored service according to another embodiment of the present invention.
  • FIG. 9 is a flowchart illustrating a simplified approval procedure of an application sponsored service according to an embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating a simplified release procedure of an application sponsored service according to an embodiment of the present invention.
  • 11 is a flowchart illustrating an approval procedure of a communication sponsored service according to an embodiment of the present invention.
  • FIG. 12 is a flowchart illustrating a simplified approval procedure of a communication sponsored service according to an embodiment of the present invention.
  • FIG. 13 is a flowchart illustrating a content delivery sponsor service procedure according to an embodiment of the present invention.
  • FIG. 14 is a flowchart illustrating the concept of intelligent processing and content delivery sponsor service according to an embodiment of the present invention.
  • 15 is a flowchart illustrating a procedure for moving content to a mobile communication network according to an embodiment of the present invention.
  • 16 is a flowchart illustrating an Internet service procedure utilizing contents in a mobile communication network according to an embodiment of the present invention.
  • 17 is a flowchart illustrating a content removal procedure in a mobile communication network according to an embodiment of the present invention.
  • FIG. 18 is a flowchart illustrating a process and a content sponsor service procedure according to an embodiment of the present invention.
  • 19 is a flowchart illustrating a processing unit / content moving procedure to a mobile communication network.
  • 20 is a flowchart illustrating an internet service procedure utilizing a processor / content in a mobile communication network.
  • 21 is a flowchart illustrating a processing unit / content removal procedure in a mobile communication network.
  • 22 is a flowchart illustrating an application sponsor service approval procedure of an SSC server.
  • 23 is a flowchart illustrating a procedure of setting QoS / statistics information of an application sponsored service of an SSC server.
  • 24 is a flowchart illustrating a billing information generation and transfer procedure of an SSC server.
  • 25 is a flowchart illustrating a communication sponsored service approval procedure of the SSC server.
  • 26 is a flowchart showing the intelligent processing and content delivery sponsor service procedure of the ISP server.
  • a sponsored service means a service that an Internet service provider pays for using a mobile communication network of an internet service based on an IMS.
  • FIG. 2 is a diagram illustrating the concept of an Internet service in a mobile communication network according to an embodiment of the present invention.
  • the IMS intervenes between the Internet service server 270 and the wireless terminal of the Internet service provider for the provision of Internet services, not IMS-based services. .
  • the interface in terms of control through the IMS core network also operates for Internet services.
  • a wireless terminal for a sponsored service, includes a sponsored service and a connection client.
  • the IMS core network includes an SSC server 230, which is defined as an application server (AS) that connects to a Call Session Control Function (CSCF), which is a central switching unit of the IMS.
  • AS application server
  • CSCF Call Session Control Function
  • the IMS client function may be applied to the Internet service server 270 of the Internet service provider.
  • a control interface is newly defined between the SSC client 220, the SSC server 230, and the Internet service server 270, and a new control interface is also defined with the SSC server 230 and the PCRF / PGW 280/290.
  • an SSC client 220 installed in a terminal as an operating system, a device driver, or a basic program (which is secured) of a wireless terminal, and the SSC client 220 is provided to an upper application.
  • the API is called by an application to operate as a sponsored service (Sponsored Service), the application of the wireless terminal through the API can be confirmed whether the valid sponsored service through the SSC server 230 when the application is running. have. Therefore, the present invention does not consider identification of all Internet services, but when operating as a sponsored service, it is possible to know whether it is an Internet service by calling the corresponding API.
  • the application that wants to operate as a sponsor service calls the API of the SSC client 220.
  • the function of the API is to generate IMS control messages transparently and independently to the application, and then receive approval of whether the sponsored service is valid through the IMS core network.
  • the sponsored service approval request message generated by the SSC client 220 arrives at the SSC server 230 via the CSCF 260, and if it is determined that the SSC server 230 is valid, the SSC client of the wireless terminal immediately. Approved to 220, or additionally by sending an IMS message back to the Internet service provider's Internet service server to dynamically receive the approval of the additional Internet provider. Therefore, the sponsored service can dynamically verify whether the corresponding service is valid from the IMS core network of the mobile communication network operator and the Internet service provider.
  • the conventional mobile communication network can guarantee the QoS only for the IMS service originally, and thus can not guarantee the Qos for the Internet service of the 3rd party Internet service provider.
  • QoS can be guaranteed.
  • the SSC server 230 receives and stores QoS information of the Internet service to be provided by the Internet service provider from the Internet service provider in advance.
  • the QoS information is transmitted to the gateway device of the mobile communication network at the time of confirming the approval of the sponsored service of the SSC server 230, thereby supporting the same QoS guarantee as the IMS when traffic for the sponsored service flows into the mobile communication network. Can be.
  • the SSC server 230 receiving the new information can deliver new QoS information to the gateway of the mobile communication network instead of the previous QoS information.
  • the Internet service in the corresponding service request increase area By moving the content and service itself for the network, it reduces the load on the network and supports the quality improvement of wireless subscribers and Internet service providers.
  • the wireless terminal subscriber is basically set to subscribe to the IMS core network of the mobile communication network operator.
  • the wireless terminal subscriber is assigned an identifier (ID) of the IMS, and receives a sponsored service using the ID.
  • ID identifier
  • the wireless terminal subscriber When subscribing to an IMS, there is a method in which a wireless terminal subscriber explicitly subscribes to an IMS service of a mobile communication network provider and receives an ID.
  • An inherent method is that a mobile communication network operator develops an application operating on a device such as a smart phone or a smart pad to call the functions of the SSC clients 220 and 230, and when the corresponding application is driven, the wireless terminal subscriber Have them decide whether or not to use sponsored services in the future.
  • the wireless subscriber can create and manage the following information.
  • the SSC server 230 needs to go through a process of registering itself with the SSC server 230.
  • the Internet service provider receives an ISP ID and password to be used by the Internet service provider, and additionally, if an additional identifier of the service that the user wants to provide as a sponsored service is required, Receive individual IDs (Service IDs).
  • Service IDs Receive individual IDs
  • Sponsored Service Types refers to the type of sponsored service that an Internet service provider wants to receive through a mobile network provider. This means any one of 1) application sponsor service, 2) communication sponsor service, or 3) intelligent processing and content delivery sponsor service to be described in detail below.
  • 1x supports 0x0001, 2) supports 0x0010, 3) supports 0x0100, and Sponsored Service Types 1) to 3) to OR and store the values.
  • the Service ID may be an IMS ID which may be a destination address for creating an IMS session, and may not be in the form of an IMS ID as information embedded in an IMS control message.
  • Individual services identified by Service ID can provide differentiated QoS in the mobile communication network if desired by the Internet service provider.
  • the Internet service provider should request the mobile communication network provider additional QoS information for each service ID.
  • An example of this is as follows.
  • Each sponsored service may have the above QoS parameters independently.
  • a conditional sponsored service support rule may be defined for each service ID. That is, the restriction is made so that the sponsored service can be supported only for a specific date and time, a specific place, a specific subscriber, and specific terminal types.
  • the SSC server should be able to receive and manage the following information for each sponsored service from the Internet service provider. The following are examples and additional details may be defined.
  • the Internet service provider itself also has flag information as to whether or not to approve the start of the sponsored service as follows. If the flag is yes, each time a sponsored service is requested from the wireless terminal, the Internet service provider also directly lends itself to the approval process for legitimate requests. If the flag is no, the approval request from the wireless terminal is processed at the SSC server 230 level without being delivered to the internet service provider every time.
  • the description of the present invention is to be performed based on the specific operation scenario.
  • an internet service provider that wants to provide sponsored services registers information about itself and information about specific services to be provided to the SSC server.
  • the wireless terminal subscriber who wants to use the sponsored service must register the Sponsorship ID made with the IMS ID through the SSC client 220.
  • the following description shows the two operations between the wireless terminal and the service provider.
  • FIG. 3 is a diagram illustrating a SSC server information acquisition process when accessing a mobile communication network according to an embodiment of the present invention.
  • a wireless terminal accesses a mobile communication network, it acquires its own IP address.
  • the wireless terminal connected to the mobile communication network acquires SSC server information in addition to the IP address to be used by the mobile terminal.
  • the IP address for the wireless terminal is assigned by the PDN Gateway (PGW).
  • PGW PDN Gateway
  • the SSC server may be one in the mobile communication network, but may exist in plural. If only one exists, one server manages the entire mobile communication network area, and in the case of a plurality, the mobile communication network may be divided locally and then an independent SSC server may be operated in each area. Therefore, the wireless terminal first receives an identifier or IP address of the SSC server managing the mobile communication network in the process of first entering the mobile communication network and assigning an IP address.
  • the identifier of the SSC server is basically in the form of an IMS ID.
  • the wireless terminal when the wireless terminal is dependent on a specific operator, it is also possible to plant the SSC server address in the corresponding mobile communication network in advance as a Uniform Resource Identifier (URI) type in the SSC client 220 inside the terminal.
  • URI Uniform Resource Identifier
  • the wireless terminal connected to the mobile communication network transmits the URI of the preset SSC server to the IP address through a DNS (Domain Name Service).
  • the mobile communication network that receives the request may transmit the IP address of the SSC server that manages the area based on the area of the mobile communication network to which the terminal sends a request.
  • FIG. 4 is a diagram illustrating an internal structure of a wireless terminal according to an embodiment of the present invention.
  • the SSC client 220 has an IMS Client function, and an application utilizing the same drives the corresponding function through an API.
  • the application does not need to know whether the SSC client 220 is an IMS protocol and experiences a sponsored service based on the IMS connection through a simplified command.
  • the application performs the following command at the start of the sponsored service.
  • the command is a counterpart address of the sponsored service represented by targetISPaddress, which is represented by the above ISP ID or Service ID.
  • targetISPaddress may be represented by an IP address of an Internet service server, and an ISP ID or a service ID may be entered in sponsorship_option.
  • the SSC client 220 In response to a request for a valid sponsored service, the SSC client 220 gives the following response.
  • reasonCode is used when it is necessary to convey additional additional information from the SSC client 220 to the application. On the contrary, in case of failure, the following response is sent to the application.
  • the operating system developer may implement from the beginning inside the operating system, and the mobile communication network provider provides the Internet service in the form of a software development kit (SDK) or a device-driver development kit (DDK). It may be provided to the provider, and the Internet service provider may insert and distribute it in an application that they make and distribute. It is also possible for mobile network operators to distribute additional programs that run on top of operating systems.
  • SDK software development kit
  • DK device-driver development kit
  • DDK device-driver development kit
  • the present invention may be classified into 1) an application sponsor service, 2) a communication sponsor service, or 3) an intelligent processing and content delivery sponsor service. Each specific operation will be described below.
  • FIG. 5 is a flowchart illustrating an approval procedure of an application sponsored service according to an embodiment of the present invention.
  • the application 210 supporting the sponsored service of the wireless terminal calls the API from the SSC client 220 and the API requests the SSC client 220 to start the sponsored service. If there is a sponsor service start request, the SSC client 220 transmits the sponsored service start request message CSCF, which is an IMS message, in step 505.
  • the sponsored service initiation request message is represented by an Invite message.
  • a description is made by setting that a destination address of an IMS message is a service ID among an ISP ID and a service ID initially registered by an Internet service provider, and the corresponding service ID is made in the form of an IMS ID.
  • a destination address of an IMS message is a service ID among an ISP ID and a service ID initially registered by an Internet service provider, and the corresponding service ID is made in the form of an IMS ID.
  • various combinations such as an ISP ID or an IP address are possible.
  • the Invite message should be the service ID of the Internet service provider as well as the ID of the SSC server 230 (or address, which will be uniformly described later) in the via field of the Invite message. This means that in case of sponsored service, Invite message must be delivered through SSC server. Therefore, in step 510, the CSCF transmits an Invite message to the SSC server.
  • the SSC server 230 After receiving the Invite message, the SSC server 230 proceeds to step 515 and obtains the AAA server 250 by inquiring the ISP and the wireless terminal information including the sponsored service information.
  • the SSC server 230 receives the Invite message from the wireless terminal 220 in step 520 and searches the internal database to determine whether the information of the Internet service provider designated as the destination is registered as a valid and valid sponsor. Inspect first. If a request for use of a sponsored service is made for a valid sponsor, it is again examined whether there are additional conditions for approval of the sponsored service, and if so, it is determined whether the additional conditions are met based on the current request.
  • the additional condition means the date / time, place, terminal type, etc., for which the aforementioned sponsored service is approved.
  • the information on the date / time is judged based on the current time, and the place is based on the IP address of the terminal, and the address of the wide area is checked.
  • the location of may be extracted and evaluated based on the information of the subscriber.
  • the type of the terminal may be determined by extracting from the AAA server 250 or the Device Management (DM) server based on the information of the subscriber.
  • DM Device Management
  • the SSC server 230 checks the above conditions and there is no problem, the SSC server 230 checks the SponsoredService _AuthCapability_Flag of the Internet service provider supporting the sponsored service. If the corresponding flag is yes, the flow proceeds to step 525 to transmit the Invite message to the CSCF 260, and the CSCF 260 transmits the Invite message to the ISP server 270 in step 530.
  • the Internet service provider receiving the Invite message confirms the sponsor service start request directly by the Internet service provider.
  • the Internet service provider directly confirms the sponsor service start request as follows. First, if the Internet service provider dynamically determines whether to support the sponsored service, next, if the Internet service provider wants to directly have statistical information on the wireless terminal, finally, the Internet service provider wants to dynamically adjust the QoS of the sponsored service. In this case, the internet service provider can directly confirm the sponsored service start request.
  • the destination address of the Invite message is the ISP ID or Service ID of the Internet service provider or the IP address after storing the above information as internal data.
  • step 535 the internet service provider determines whether the sponsor service request is for a valid sponsor. If it is determined that the internet service provider is valid, the server proceeds to step 540 and the ISP server 270 transmits a start approval message to the CSCF 260. In the drawing, the start approval message is indicated by a 200 OK message. In this case, when the QoS is to be changed dynamically, the QoS information on the Sponsored Service may be included in the 200 OK message as additional information and transmitted.
  • the CSCF 260 transmits the 200 OK message received in step 545 to the SSC server 230.
  • the SSC server 230 updates the Qos information that has received the Qos information that it has.
  • the SSC server 230 confirms that the sponsored service is valid by checking a 200 OK message in step 550, proceeds to step 555, and transmits an initiation approval message to the CSCF 260, and transmits QoS information and policy in PGW / PCRF in step 560. To send.
  • the CSCF 260 then sends a start acknowledgment message to the SSC client 220 in step 565.
  • the SSC client 220 transmits an acknowledgment message to the CSCF 260 in step 570.
  • the acknowledgment message is indicated by an ACK message.
  • the CSCF 260 transmits an ACK message to the SSC server 230.
  • the SSC server 230 transmits an ACK message message to the CSCF 260.
  • the CSCF 260 sends an ACK message. Send the message to ISP server 270.
  • step 570 the SSC client 220 transmits an ACK message message to the CSCF 260 and informs the sponsored service connection success information thereof of its own Graphic User Interface (GUI). This is done independently of the application, and allows the user to use the sponsored services with confidence.
  • GUI Graphic User Interface
  • a sponsored service session is created between the application 210 and the ISP server 270 in step 595.
  • FIG. 6 is a flowchart illustrating a release procedure of an application sponsored service according to an embodiment of the present invention.
  • the application 210 calls Sponsorship_Release_Request () for the termination of the sponsored service through the API.
  • the SSC client 220 receives the termination request message to the CSCF 260.
  • the termination request message is an IMS message, indicated by Bye message in the drawing.
  • the CSCF transmits a Bye message to the SSC server.
  • the SSC server 230 first recognizes the end of the service, and proceeds to step 615 to collect information such as the amount of transmission and reception traffic used by the sponsor service in the PGW (280).
  • the SSC server 230 forms the collected information in the form of Call Detail Recording (CDR) that can be understood by the billing server and delivers the information to the AAA (Authentication / Authorization / Accounting) server 250.
  • the SSC server 230 transmits a Bye message to the CSCF, and in step 630, the CSCF transmits a Bye message to the ISP server.
  • CDR Call Detail Recording
  • the SSC server 230 processes the information on the billing, such as the amount of traffic received through the PGW 280 in a form that is easy for users to understand, and then included in the Bye message to be delivered to the Internet service provider. Through this, the Internet service provider can check the statistical information on the charge immediately after each sponsor service session is finished.
  • the Internet service provider transmits the termination acknowledgment message to the CSCF in step 635 in response to the Bye message.
  • the end acknowledgment message is indicated by a 200 OK message in the figure.
  • the CSCF transmits a 200 OK message to the SSC server 230.
  • the SSC server 230 transmits a 200 OK message to the CSCF 260.
  • the CSCF sends a 200 OK message to the SSC client ( 220).
  • the 200 OK message like the Bye message, includes statistical information about the charge.
  • the SSC client 220 receiving the information shows the charging information to the wireless terminal user in step 655, so that the SSC client 220 can immediately check how much the sponsored service cost was used when the service was terminated. Finally, the SSC client 220 delivers the Sponsorship_Release_Response () response to the application through the API.
  • FIG. 7 is a flowchart illustrating a procedure for rejecting an application sponsored service according to an embodiment of the present invention
  • FIG. 8 is a flowchart illustrating a process for rejecting an application sponsored service according to another embodiment of the present invention.
  • FIG. 7 illustrates a case in which the SSC server 230 disallows the approval of the sponsored service
  • FIG. 8 illustrates a case in which the server 260 of the Internet service provider does not permit the approval of the sponsored service.
  • each server rejects the case where it is determined that it is not valid in the process of determining the validity of the sponsored service at the corresponding time, and transmits an approval rejection message to the terminal. In this case, it is impossible to use the sponsored service in the wireless terminal.
  • the application 210 supporting the sponsored service of the wireless terminal calls an API from the SSC client 220, and the API requests the SSC client 220 to start the sponsored service. If there is a sponsor service start request, the SSC client 220 transmits the sponsored service start request message CSCF, which is an IMS message, in step 710. In the figure, the sponsored service initiation request message is represented by an Invite message. Thereafter, in step 720, the CSCF transmits an Invite message to the SSC server.
  • the SSC server 230 After receiving the Invite message, the SSC server 230 proceeds to step 730 and obtains the AAA server 250 by inquiring the ISP and the wireless terminal information including the sponsored service information.
  • the SSC server 230 receives the Invite message from the wireless terminal 220 in step 740.
  • the SSC server 230 searches the internal database and registers as a valid sponsor with the correct information of the Internet service provider designated as the destination. First check to see if it is. At this time, if the SSC server 230 determines that the sponsor service use request for the invalid sponsor proceeds to step 750 and transmits an approval rejection message to the CSCF (260). The rejection message is indicated by the 488 Reject message in the figure.
  • the CSCF 260 transmits the 488 Reject message received in step 760 to the SSC client 220. Thereafter, the SSC client 220 informs the sponsored service connection failure of the SSC client 220 in its own Graphic User Interface (GUI) in step 770. Finally, the SSC client 220 communicates the sponsored service connection failure to the application 210 via the API.
  • GUI Graphic User Interface
  • the application 210 supporting the sponsored service of the wireless terminal calls the API from the SSC client 220 and the API requests the SSC client 220 to start the sponsored service. If there is a sponsor service start request, the SSC client 220 transmits the sponsored service start request message CSCF, which is an IMS message, in step 805.
  • the sponsored service initiation request message is represented by an Invite message. Thereafter, in step 810, the CSCF transmits an Invite message to the SSC server.
  • the SSC server 230 After receiving the Invite message, the SSC server 230 proceeds to step 815 and obtains the AAA server 250 by inquiring the ISP and the wireless terminal information including the sponsored service information.
  • the SSC server 230 receives the Invite message from the wireless terminal 220 in step 820 and searches the internal database to determine whether the information of the Internet service provider designated as the destination is registered as a valid and valid sponsor. Inspect first. If a request for use of a sponsored service is made for a valid sponsor, it is again checked whether there are additional conditions for approval of the sponsored service, and if so, it is determined whether the additional conditions are met based on the current request.
  • the additional condition means the date / time, place, terminal type, etc., for which the aforementioned sponsored service is approved.
  • the information on the date / time is judged based on the current time, and the location is based on the IP address of the terminal, and the address of the wide area is checked. The location of may be extracted and evaluated based on the information of the subscriber.
  • the type of the terminal may be determined by extracting from the AAA server 250 or the Device Management (DM) server based on the information of the subscriber.
  • DM Device Management
  • the SSC server 230 checks the above conditions and there is no problem, the SSC server 230 checks the SponsoredService _AuthCapability_Flag of the Internet service provider supporting the sponsored service. If the corresponding flag is yes, the flow proceeds to step 825 to transmit the Invite message to the CSCF 260, and the CSCF 260 transmits the Invite message to the ISP server 270 in step 530.
  • the Internet service provider receiving the Invite message confirms the sponsor service start request directly by the Internet service provider.
  • the internet service provider determines whether the sponsor service request is for a valid sponsor. If it is determined that the internet service provider is not valid, the ISP server 270 transmits an approval rejection message to the CSCF 260 in step 840. The rejection message is indicated by the 488 Reject message in the figure.
  • the CSCF 260 transmits the 488 Reject message received in step 845 to the SSC server 230.
  • the SSC server 230 confirms that the sponsored service is not valid by checking the 488 Reject message in step 850, and proceeds to step 855 to transmit the 488 Reject message to the SSC client 220 in step 860 via the CSCF 260. do.
  • the SSC client 220 informs the sponsored service connection failure of the SSC client 220 in its own Graphic User Interface (GUI) in step 770.
  • GUI Graphic User Interface
  • the SSC client 220 communicates the sponsored service connection failure to the application 210 via the API.
  • the Internet service provider must also be able to understand the IMS, and the function to process it should be embedded in the server.
  • adding a new IMS function to an existing service server may be difficult, and it may be a burden for an Internet service provider to understand IMS, which is a technology of mobile communication networks and telecommunication network providers. Therefore, a simplified procedure for solving this is shown in FIGS. 9 and 10.
  • FIG. 9 is a flowchart illustrating a simplified approval procedure of an application sponsor service according to an embodiment of the present invention
  • FIG. 10 is a flowchart illustrating a simplified release procedure of an application sponsor service according to an embodiment of the present invention.
  • FIG. 9 may be basically referred to as a subset of FIG. 5.
  • the SSC server 230 determines the determination of the sponsored service, the response is immediately transmitted to the wireless terminal. Therefore, the difference from FIG. 5 is that the final destination of the Invite message is functionally the SSC server 230, and the ISP ID and the Service ID are transmitted to the SSC server 230 as data of the Invite message for identification of the sponsored service. Process other than this is the same as FIG.
  • steps 905-920 are the same as steps 505-520.
  • the SSC server 230 searches the internal database to register the information as a valid and valid sponsor of the Internet service provider designated as the destination. Check if it is If a request for use of a sponsored service is made for a valid sponsor, it is again checked whether there are additional conditions for approval of the sponsored service, and if so, it is determined whether the additional conditions are met based on the current request.
  • the additional condition means the date / time, place, terminal type, etc., for which the aforementioned sponsored service is approved.
  • the information on the date / time is judged based on the current time, and the place is based on the IP address of the terminal, and the address of the wide area is checked.
  • the location of may be extracted and evaluated based on the information of the subscriber.
  • the type of the terminal may be determined by extracting from the AAA server 250 or the Device Management (DM) server based on the information of the subscriber.
  • DM Device Management
  • the SSC server 230 checks the above conditions and there is no problem, unlike the embodiment shown in FIG. 5, the SSC server 230 does not check the SponsoredService _AuthCapability_Flag of the Internet service provider supporting the corresponding sponsored service in step 925. ) Sends a start acknowledgment message to the CSCF 260.
  • the SSC server 230 transmits the QoS information and the policy to the PGW / PCRF.
  • the start approval message is indicated by a 200 OK message. In this case, it is impossible for an internet service provider to dynamically change QoS.
  • the CSCF 260 transmits the received 200 OK message to the SSC client 220 in step 935.
  • the SSC client 220 transmits an acknowledgment message to the CSCF 260 in step 940.
  • the acknowledgment message is indicated by an ACK message.
  • the CSCF 260 transmits an ACK message to the SSC server 230.
  • the SSC client 220 After the SSC client 220 transmits the ACK message message to the CSCF 260, in step 945, the SSC client 220 informs the sponsored service connection of the sponsored service as its own Graphic User Interface (GUI). This is done independently of the application, and allows the user to use the sponsored services with confidence.
  • GUI Graphic User Interface
  • step 955 a sponsored service session between the application 210 and the ISP server 270 is created.
  • the disconnection procedure shown in FIG. 6 may be considered to be the final work in the SSC server 230, and the procedure for this is shown in FIG. 10.
  • the final destination of the Bye message is the SSC server 230, and the ISP ID and the Service ID are transmitted to the SSC server 230 as data of the Bye message to identify the sponsored service.
  • Other procedures are the same as in FIG. 6.
  • steps 605-620 are the same as steps 1010-1040.
  • the SSC server 230 transmits an end acknowledgment message to the CSCF 260 in step 1050.
  • the end acknowledgment message is indicated by a 200 OK message in the figure.
  • the CSCF 260 transmits a 200 OK message to the SSC client 220.
  • the 200 OK message like the Bye message, includes statistical information about the charge.
  • the SSC client 220 receiving the information shows the billing information to the wireless terminal user in step 1070 so that the user can immediately check how much the sponsored service cost was used at the end of the service. Finally, the SSC client 220 delivers the Sponsorship_Release_Response () response to the application through the API.
  • FIG. 11 is a flowchart illustrating an approval procedure of a communication sponsored service according to an embodiment of the present invention.
  • the difference between the service sponsored service and the service sponsored service is that the wireless subscriber does not receive the service from the server of the Internet service provider, but the Internet service provider pays for the communication service such as voice / video phone of the mobile network service provider.
  • the condition is that it can be performed between wireless subscribers.
  • the cost is the same as that of the company.
  • an internet service provider if a communication service between users is required in its service (for example, communication between a wireless terminal user and its person in charge), the internet service provider directly develops and operates the communication service. If not, it can be said that it is borrowing the infrastructure of the mobile network operator.
  • the application 210 supporting the sponsored service of the wireless terminal calls the API from the SSC client 220, the API requests the SSC client 220 to start the sponsored service. If there is a sponsor service start request, the SSC client 220 transmits the sponsored service start request message CSCF, which is an IMS message, in step 1103.
  • the sponsored service initiation request message is represented by an Invite message.
  • the destination address of the IMS Invite message is the other party's subscriber, and the via field becomes SSC server 230 as well.
  • the ISP ID and the Service ID are included in the data field in the sense that the Internet service provider supports the corresponding communication service.
  • the service ID may be assigned to a communication service. In this case, the service ID may be set to differentiate the QoS quality of the communication service requested by the Internet service provider.
  • the CSCF 260 transmits the Invite message to the SSC server 230.
  • the SSC server 230 After receiving the Invite message, the SSC server 230 proceeds to step 1109 and inquires of the ISP and the wireless terminal information including the sponsored service information by the AAA server 250.
  • the SSC server 230 determines whether it is a valid sponsored service through the ISP ID in the data field of the Invite message in step 1112, and then determines whether there is QoS parameter setting information of the gateway. Check through. If it is a valid sponsor service use request, the SSC server 230 proceeds to step 1115 and transmits an Invite message to the CSCF 260, and the CSCF 260 transmits an Invite message to the ISP server 270 in step 1118. Since there is already an ISP ID in the message sent by the wireless terminal, it is applied to the via field and transmitted.
  • the Internet service provider determines whether the sponsor service request is for a valid sponsor. If it is determined that the internet service provider is valid, the ISP server 270 transmits the Invite message to the CSCF 260 in step 1124. The CSCF 260 transmits the Invite message received in step 1127 to the counterpart wireless terminal 225.
  • the other party's wireless terminal 225 transmits a start approval message to the CSCF 260 in step 1130.
  • the start approval message is indicated by a 200 OK message.
  • the CSCF 260 transmits the 200 OK message received in step 1133 to the ISP server 270, and the ISP server 270 sends it back to the CSCF 260 in step 1136 after checking it, and the CSCF 260 receives 1139.
  • the 200 OK message received in the step is transmitted to the SSC server 230.
  • the SSC server 230 confirms that the sponsored service is valid by checking the 200 OK message in step 1142, proceeds to step 1145, and transmits a start approval message to the CSCF 260, and transmits the QoS information and policy in PGW / PCRF in step 1148. To send. Thereafter, the CSCF 260 transmits a start approval message to the SSC client 220 in step 1154.
  • the SSC client 220 transmits an acknowledgment message to the CSCF 260 in step 1154.
  • the acknowledgment message is indicated by an ACK message.
  • the CSCF 260 transmits an ACK message to the SSC server 230.
  • the SSC server 230 transmits an ACK message message to the CSCF 260.
  • the CSCF 260 sends an ACK message. Send the message to ISP server 270.
  • the ISP server 270 transmits the ACK message message to the CSCF 260 in step 1169, and the CSCF 260 transmits the ACK message message to the counterpart terminal 225 in step 1172.
  • step 1157 the SSC client 220 transmits an ACK message message to the CSCF 260 and informs the sponsor service connection success of the SSC client 220 as its own Graphic User Interface (GUI). This is done independently of the application, and allows the user to use the sponsored services with confidence.
  • GUI Graphic User Interface
  • step 1175 a sponsored service session between the application 210 and the ISP server 270 is generated.
  • the disconnection procedure of the communication sponsor service is similar to the embodiment shown in FIG. 6 and will not be described separately.
  • the communication sponsor service can be implemented without the Internet service provider not knowing the IMS.
  • FIG. 11 a procedure for the SSC server 230 to make a final decision is shown in FIG. 12.
  • Each node performs the same function as the embodiment shown in FIG. 11 except that the internet service provider disappears in the connection establishment process.
  • FIG. 12 is a flowchart illustrating a simplified approval procedure of a communication sponsored service according to an embodiment of the present invention.
  • steps 1205-1225 are the same as steps 1103-1115.
  • the CSCF 260 transmits the Invite message to the counterpart wireless terminal 225 in step 1230. After checking the Invite message, the other party's wireless terminal 225 transmits a start approval message to the CSCF 260 in step 1235. In the drawing, the start approval message is indicated by a 200 OK message.
  • the CSCF 260 transmits the 200 OK message received in step 1240 to the SSC server 230.
  • the SSC server 230 confirms that the sponsored service is valid by checking the 200 OK message in step 1245, and proceeds to step 1250 to transmit the start approval message to the CSCF 260, and in step 1255, the PGW / Transfer to PCRF. Thereafter, the CSCF 260 transmits a start approval message to the SSC client 220 in step 1260.
  • the SSC client 220 transmits an acknowledgment message to the CSCF 260 in step 1265.
  • the acknowledgment message is indicated by an ACK message.
  • the CSCF 260 transmits an ACK message to the SSC server 230, and in step 1280, the SSC server 230 transmits an ACK message message to the CSCF 260, and in step 1285, the CSCF 260 sends an ACK message.
  • Message The message is transmitted to the counterpart terminal 225.
  • step 1270 the SSC client 220 transmits an ACK message message to the CSCF 260 and informs the sponsor service connection success of the SSC client 220 as its own Graphic User Interface (GUI). This is done independently of the application, and allows the user to use the sponsored services with confidence.
  • GUI Graphic User Interface
  • step 1270 a sponsored service session between the application 210 and the ISP server 270 is generated.
  • FIG. 13 is a flowchart illustrating a content delivery sponsor service procedure according to an embodiment of the present invention.
  • steps 1310, 1330, and 1340 of FIG. 13 are performed. That is, in step 1310, when the wireless terminal accesses the application service server through a transport protocol such as Hyper Text Transport Protocol (HTTP), in step 1330, if the application service server sends a response and needs to transmit additional content, the response is applied to the response. It informs the name and location of the storage server where the content is stored.
  • HTTP Hyper Text Transport Protocol
  • step 1340 the wireless terminal goes back to the storage server where the corresponding content is stored and reads the content file of the location.
  • the wireless terminal performs the procedure as shown in FIG. 5 before the transmission of HTTP or the like, so that content transmission and reception with the corresponding storage server is supported as a sponsored service.
  • the intelligent service is an intelligent processing and content delivery sponsor service according to the present invention.
  • step 1320 the content request matrix is updated or confirmed, and in step 1350, when the sponsor application service server IP address replacement report is transmitted, a process of transmitting a sponsor application service IP address replacement response is added. Thereafter, in step 1370, the sponsored content is transmitted.
  • the wireless terminal transmits information of the SSC server 230 when accessing the service server of the Internet service provider.
  • This is inherent in the sequence 1 of FIG. 13, and the present invention is for informing the Internet service server of the SSC server 230 in charge of the point where the wireless terminal is connected.
  • the Internet service server provides a service through its processor and storage device as shown in FIG. 13, and the content request in a specific area is excessively generated beyond a certain level, the Internet service server is responsible for the area as shown in 2) of FIG. 14.
  • Ask the SSC server 230 to transfer the contents of the Internet service server instead. That is, the excessive traffic from the Internet service server is transmitted to the mobile communication network, and is not transmitted to the wireless terminals again through the wireless, and the SSC server 230 closest to the wireless transmits the contents of the Internet service server.
  • the process of moving the actual content to the content storage server managed by the SSC server 230 of the mobile communication network is shown in 3). Subsequently, when a request for the corresponding content comes from the jurisdiction of the SSC server 230, the corresponding content is replaced by the servers under the SSC server 230 on behalf of the Internet service server of the SSC server 230 Internet service provider. Is sent. Therefore, the delay time caused by the transmission of traffic from the Internet service server to the mobile communication network is reduced. In addition, since the response is directly transmitted to the wireless terminal within the mobile communication network close to the radio, the quality of service is improved.
  • the SSC server (Controller) 231 transmits a message requesting to transmit the content agency.
  • the SSC server (Controller) 231 transmits information on the characteristics of the content requested to be transmitted on behalf of the ISP ID. If the SSC server (Controller) 231 determines that the content can be transmitted on the basis of the corresponding information, the SSC server (231) transmits a response back to the ISP server (Controller) 271 that it is possible in step 1520.
  • the ISP server 271 Upon receiving this, the ISP server 271 requests its storage server 272 to transmit its contents to the storage server 232 under the S230 server 230 in step 1530. In step 1540, the content is transmitted.
  • the SSC server 231 checks the content in step 1550 and stores the content received in step 1560 in the SSC server 232. Thereafter, when content transmission between storage servers is terminated, the SSC server 230 generates an access URI for the corresponding content in step 1570 and delivers a confirmation message including the same to the ISP server (Controller) 271.
  • the ISP makes a new location of the file in the storage server 232 as a URI.
  • the SSC server 230 additionally, in order to ensure the quality of services using the storage server 232 as a content storage location, and to secure statistical information for charging a fee instead of sponsoring the service, step 1580.
  • the information on the corresponding content is transferred to the gateway so that the gateway such as PGW 280 / PCRF 290 provides differentiated quality for transmission of the moved content and collects statistical information.
  • the setting for this is also transmitted to the corresponding PGW 280 / PCRF 290 in step 1580.
  • 16 is a flowchart illustrating an Internet service procedure utilizing contents in a mobile communication network according to an embodiment of the present invention.
  • the wireless terminal 210 transmits a request to the ISP server 271 for the content transferred in step 1610
  • the ISP server 271 receives the content in step 1620.
  • a response including the storage server URI under the SSC server 230 is transmitted to the location of the content.
  • the wireless terminal 210 quickly accesses the content in the storage server 232 of the SSC server 230 and receives the content in step 1650.
  • the storage server 232 under the SSC server 230 generates billing information for each case in step 1660 and delivers the billing information to the AAA server, thereby performing billing for the Internet service provider.
  • the ISP server 271 may determine how much of the content request comes from the wireless terminal 210 as a gateway for the content transmission request. Therefore, if the request for the content delivered to the storage server under the SSC server 230 decreases for a predetermined time, the Internet service provider removes the content moved into the corresponding mobile communication network, and directly transfers the content to the wireless terminal. Can come out.
  • 17 is a flowchart illustrating a content removal procedure in a mobile communication network according to an embodiment of the present invention.
  • the SSC server 271 transfers the ISP ID that informs the SSC server 231 to the SSC server 231 and the URI of the content that the SSC server 231 informs at the time of the previous content transfer. Request to stop the transfer of agents.
  • the SSC server 231 receives the content in step 1720, and then removes the content from the storage server 232 under the control in step 1730, and responds to the content removal response in step 1740 by the ISP server (controller) ( 271). Thereafter, in step 1750, the information on the content finally transmitted on behalf of the agent is transmitted to the billing server.
  • CDN content delivery network
  • the ISP server 271 may use an HTTP request requested from a wireless terminal. It only needs to receive the message and immediately resends it to the server under the SSC server 230 on the processor temporarily borrowed from the mobile communication network.
  • FIGS. 18-21 Such a procedure is illustrated in FIGS. 18-21. This process corresponds to FIGS. 15 to 17.
  • FIG. 18 is a flowchart illustrating a process and a content sponsor service procedure according to an embodiment of the present invention.
  • the ISP server 271 updates or checks the content request matrix in step 1820.
  • the response including the ID of the ISP server 270 where the content is located is delivered.
  • the wireless terminal 210 requests the network service to the ISP server 270 changed in step 1840, and if necessary, sends the sponsor ISP server 270 'IP address replacement report to the PGW 280 / PCRF 290 in step 1850. send.
  • the PGW 280 / PCRF 290 transmits the sponsor ISP server 270 ′ IP address replacement response to the wireless terminal 210.
  • a processing / storage session is created between the wireless terminal 210 and the sponsor ISP server 270 '.
  • 19 is a flowchart illustrating a processing unit / content moving procedure to a mobile communication network.
  • the SSC server (Controller) 231 transmits a message requesting to transmit the content agency. If the SSC server (Controller) 231 determines that the content can be transmitted on the basis of the information, the SSC server (231) transmits a response back to the ISP server (Controller) (271). Upon receiving this, the ISP server 271 requests to transmit an application and content stored in the ISP server 270 in step 1930. Thereafter, the content is transmitted in step 1940.
  • the SSC server (Controller) 231 checks the content in step 1950, and stores the application and content received in step 1960 in the SSC server 230. Thereafter, when the content transmission is completed, the SSC server 231 generates an access URI for the corresponding content in step 1970 and delivers a confirmation message including the same to the ISP server 271.
  • the SSC server 230 additionally ensures the quality of the services using the storage server 232 as the content storage location, and also secures statistical information for charging a fee to be charged instead by the sponsored service.
  • the information on the corresponding content is transferred to the gateway so that the gateway such as PGW 280 / PCRF 290 provides differentiated quality for transmission of the moved content and collects statistical information.
  • the setting for this is also transmitted to the corresponding PGW 280 / PCRF 290 in step 1580.
  • 20 is a flowchart illustrating an internet service procedure utilizing a processor / content in a mobile communication network.
  • the wireless terminal 210 transmits a request to the ISP server 271 for the content transferred in step 2010, the ISP server 271 updates or verifies the content request matrix in step 2020.
  • a response including the storage server URI under the SSC server 230 is transmitted to the location of the content.
  • the wireless terminal 210 requests the network service to the SSC server 230 when the content is accessed in step 2040, and generates a sponsored processing and content session in step 2050.
  • the SSC server 230 generates billing information for each case in step 2060 and delivers the billing information to the AAA server 250, through which billing is performed for the Internet service provider.
  • 21 is a flowchart illustrating a processing unit / content removal procedure in a mobile communication network.
  • the ISP server 271 transfers the ISP ID that informs the SSC server 231 of the SSC server 231 and the URI of the application and the content that the SSC server 231 informs when the application and the content are transferred. To stop the transfer of the application and the content.
  • the SSC server 231 receives the content in step 2120, and then removes the application and the content from the storage server 232 under the control in step 2130. To 271). Thereafter, in step 2150, the information of the content finally transmitted on behalf of the agent is transmitted to the billing server.
  • 22 is a flowchart illustrating an application sponsor service approval procedure of an SSC server.
  • the SSC server 230 extracts the sponsorship ID, the IDP ID and the service ID from the Invite message received in step 2205, and extracts the sponsored service information corresponding to the ISP ID and the service ID in step 2210.
  • the SSC server 230 determines whether it is a valid ISP ID or service ID in step 2215. If the SSC server 230 determines that it is a valid ISP ID or service ID, the SSC server 230 proceeds to step 2220 to determine whether a date / time option exists. If the SSC server 230 determines that the date / time option does not exist, the SSC server 230 proceeds to step 2230 to determine whether the local option exists. If the SSC server 230 determines that the region option does not exist, the SSC server 230 proceeds to step 2240 to determine whether the ID option exists. If the SSC server 230 determines that the ID option does not exist, the process proceeds to step 2260 to approve the request and transmits an Invite message to the ISP server 270 with an OK result.
  • step 2215 If it is determined in step 2215 that the SSC server 230 is an invalid ISP ID or service ID, the SSC server 230 proceeds to step 2250 to record abnormal usage in the database. Thereafter, the process proceeds to step 2270 and ignores the request and transmits a 488 rejection message with the NOK result to the user terminal.
  • step 2220 determines whether it is a valid date / time in step 2225, and the SSC server 230 determines a valid date / time. If it is determined that the time, go to step 2230. If the SSC server 230 determines that the date / time is not valid, the process proceeds to step 2250.
  • step 2230 the SSC server 230 determines whether it is a valid region in step 2235, and if it is determined that the SSC server 230 is a valid region 2230. Proceed to step. If the SSC server 230 determines that the area is not valid, the process proceeds to step 2250.
  • step 2230 determines whether it is a valid ID in step 2245, and if the SSC server 230 determines that it is a valid ID 2260. Proceed to step. If the SSC server 230 determines that the area is not valid, the process proceeds to step 2250.
  • 23 is a flowchart illustrating a procedure of setting QoS / statistics information of an application sponsored service of an SSC server.
  • the SSC server 230 extracts the result from the 200 OK message in step 2310. Thereafter, in step 2320, it is determined whether the result is OK. If the result is extracted, the SSC server 230 proceeds to step 2330 to determine whether the QoS information exists. If the QoS information exists, the SSC server 230 proceeds to step 2350 to extract the QoS information from the OK message. Thereafter, the SSC server 230 proceeds to step 2360 to update the QoS information for the service ID.
  • the SSC server 230 generates a QoS and policy enforcement message in operation 2370 and transmits the QoS and policy enforcement message to the gateway in operation 2380. Thereafter, in step 2390, the 200 OK message is delivered to the user terminal.
  • step 2320 If the SSC server 230 does not extract the result in step 2320, the process proceeds to step 2390.
  • step 2330 the SSC server 230 proceeds to step 2340 to extract QoS information for the service ID from the database message and proceeds to step 2370.
  • 24 is a flowchart illustrating a billing information generation and transfer procedure of an SSC server.
  • the SSC server 230 extracts CDR information from the PGW in step 2410. Thereafter, in step 2420, the SSC server 230 adds the account information to the CDR, and in step 2430, the CDR is transmitted to the AAA server. Next, the SSC server 230 proceeds to step 2440 to generate call charge summary information, to step 2450 to add call charge summary information to the Bye message, and to proceed to step 2460 to transfer the Bye message to the ISP server. .
  • the SSC server 230 determines whether a 200 OK message is received from the ISP server in step 2470. If the SSC server 230 determines that the 200 OK message has been received, the SSC server 230 adds call charge summary information to the 200 OK message in step 2480 and delivers the 200 OK message to the user terminal in step 2490. .
  • step S470 is performed again.
  • 25 is a flowchart illustrating a communication sponsored service approval procedure of the SSC server.
  • the SSC server 230 extracts the sponsorship ID, the IDP ID and the service ID from the Invite message received in step 2505, and extracts the ISP ID and the service ID in step 2210.
  • the SSC server 230 determines whether it is a valid counterpart terminal in step 2510. If it is determined that the SSC server 230 is a valid counterpart terminal, the process proceeds to step 2515 to determine whether the counterpart terminal is an IMS ID. If the SSC server 230 determines that the other terminal is the IMS ID, in step 2520, the SSC server 230 extracts sponsor service information corresponding to the ISP ID and the service ID.
  • the SSC server 230 determines whether it is a valid ISP ID or service ID in step 2525. If the SSC server 230 determines that it is a valid ISP ID or service ID, the SSC server 230 proceeds to step 2530 to determine whether a date / time option exists. If the SSC server 230 determines that the date / time option does not exist, the SSC server 230 proceeds to step 2540 to determine whether the local option exists. If the SSC server 230 determines that the region option does not exist, the SSC server 230 proceeds to step 2550 to determine whether the ID option exists. If the SSC server 230 determines that the ID option does not exist, the process proceeds to step 2565 to approve the request and transmits an Invite message to the ISP server 270 with an OK result.
  • step 2525 If it is determined in step 2525 that the SSC server 230 is an invalid ISP ID or service ID, the SSC server 230 proceeds to step 2560 to record abnormal usage in the database. Thereafter, the process proceeds to step 2570 and ignores the request and transmits a 488 rejection message to the user terminal with the NOK result.
  • step 2530 determines whether a date / time option exists in step 2530, the SSC server 230 determines whether it is a valid date / time in step 2535, and the SSC server 230 determines a valid date / time. If it is determined that the time, go to step 2540. If the SSC server 230 determines that the date / time is not valid, the process proceeds to step 2560.
  • step 2540 the SSC server 230 determines whether it is a valid region in step 2545, and if it is determined that the SSC server 230 is a valid region 2550. Proceed to step. If the SSC server 230 determines that the area is not valid, the process proceeds to step 2560.
  • step 2550 the SSC server 230 determines whether it is a valid ID in step 2555, and if the SSC server 230 determines that it is a valid ID 2265. Proceed to step. If the SSC server 230 determines that the area is not valid, the process proceeds to step 2560.
  • 26 is a flowchart showing the intelligent processing and content delivery sponsor service procedure of the ISP server.
  • the ISP server 271 extracts the SSC server ID from the HTTP request message in step 2605. Thereafter, the ISP server 271 determines whether it is a new SSC server ID in step 2610. If the ISP server 271 determines that it is not the new SSC server ID, the process proceeds to step 2615 to extract processing information from the database. Thereafter, the ISP server 271 determines whether the frequency reaches a threshold in step 2625. If the ISP server 271 determines that the frequency reaches the threshold, the controller 271 proceeds to step 2630 and accesses the SSC server to transmit the content.
  • the ISP server 271 determines whether to permit transmission in step 2635. If the ISP server 271 determines that the transmission is permitted, the process proceeds to step 2640 to transmit the content to the SSC server 230.
  • the ISP server 271 determines whether a new URI is received in step 2645. If the ISP server 271 determines that the new URI has been received, the process proceeds to step 2650 to add the URI to the database and proceeds to step 2655 to generate a new HTML page for the content using the new URI.
  • the controller 271 adds SSC server account information to the CDR and terminates.
  • the ISP server 271 determines that the frequency has not reached the critical point in step 2625, it immediately ends.
  • step 2635 If the ISP server 271 determines that the transmission is not permitted in step 2635, the process is terminated immediately.
  • the ISP server 271 determines that a new URI has not been received in step 2645, it immediately ends.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Tourism & Hospitality (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명은 IMS 기반의 이동통신 네트워크에서 스폰서 서비스(Sponsored Service) 제공하는 방법 및 시스템에 관한 것으로, 스폰서 서비스 클라이언트가 스폰서 서비스 서버에 스폰서 서비스 개시 요청 메시지를 전송하는 단계; 스폰서 서비스 서버가 개시 요청 메시지 수신 후, 스폰서 서비스의 유효 여부를 판단하는 단계; 스폰서 서비스 서버가 스폰서 서비스가 유효하다고 판단하는 경우, 스폰서 서비스 개시 승인 메시지를 상기 스폰서 서비스 클라이언트로 전송하는 단계; 스폰서 서비스 클라이언트와 인터넷 서비스 제공 서버 간 스폰서 서비스 세션을 생성하는 단계; 스폰서 서비스 클라이언트의 스폰서 서비스 종료 요청 시, 스폰서 서비스 서버가 과금 정보를 생성하고 AAA 서버(Authentication/Authorization/ Accounting Sever)로 상기 과금정보를 전송하는 단계; 및 스폰서 서비스 세션을 종료하는 단계를 포함하는 것을 특징으로 한다. 본 발명에 따르면, 무선단말가입자의 이동통신 네트워크 사용 비용을 3rd Party 인터넷서비스 제공사업자가 대신 지불하는 스폰서 서비스를 제공할 수 있다. 스폰서 서비스가 제공 시, 차별화된 서비스 품질을 제공할 수 있고, 해당 서비스 품질은 해당 인터넷서비스가 개시하는 시점에서 동적으로 제어가 가능하다.

Description

IMS 기반의 이동통신 네트워크에서 스폰서 서비스 제공 방법 및 시스템
본 발명은 IMS 기반의 이동통신 네트워크에서 인터넷 서비스 제공 서버(Internet Service Provider Server)가 단말의 이동통신 사용 요금을 대납할 수 있는 스폰서 서비스(Sponsored Service) 제공하는 방법 및 시스템에 관한 것이다.
일반적으로 이동통신 네트워크 사업자는 IP Multimedia Subsystem(이하, IMS) 코어 네트워크를 통하여 IP 기반 멀티미디어 서비스를 제공한다. 하지만 외부 3rd Party 인터넷서비스 제공사업자의 인터넷서비스의 경우, 이동통신 네트워크 사업자의 일반 IP 네트워크를 통하여 무선단말가입자에게 제공되며, IMS 코어 네트워크는 아무런 작업을 하지 않는다. 이러한 종래 기술의 이동통신 네트워크에서 인터넷 서비스 개념이 도 1에 도시되어 있다.
종래 기술에 따르면, 3rd Party 인터넷서비스 제공사업자의 인터넷서비스가 무선단말가입자에게 제공되는 경우, 해당 인터넷서비스 제공사업자가 광고 수익 등을 통하여 무선단말가입자로부터 획득한 이익을, 다시 해당 무선단말가입자에게 돌려주기 위한 수단으로서, 해당 무선단말가입자가 사용한 인터넷서비스제공사업자의 인터넷서비스에 대한 이동통신 네트워크 사용비용을 대신 제공해 줄 수 있는 방법이 없다는 문제점이 있다.
또한, 이동통신 네트워크에서는 인터넷서비스에 대한 정보를 갖지 않으므로 인터넷서비스 제공사업자가 QoS 등을 이용하여 차별화된 품질을 제공하는 것도 불가능하다. 종래 기술에 따르면, 3rd Party 인터넷서비스 제공사업자의 인터넷서비스와 이동통신 네트워크는 아무런 관련성이 없어 이동통신 네트워크에서 인터넷서비스를 식별하여 그에 맞는 최적화되고 동적으로 통제가 되는 서비스 품질 개선 등을 지원하는 것이 불가능하다는 문제점도 있다.
아울러 무선단말과 인터넷서비스 제공사업자간의 물리적인 위치가 멀어서 발생하는 전송/처리 지연 등의 문제로 인하여 사용자가 체감하는 인터넷 서비스의 이동통신 네트워크에서의 품질 수준이 매우 낮다는 문제점도 있다.
본 발명은 상기와 같은 문제점을 해결하기 위하여 안출된 것으로서, 무선단말 가입자가 IMS 기반의 이동통신 네트워크를 통하여 3rd Party 인터넷서비스 제공사업자가 인터넷서비스를 이용하는 경우, 통신시간 및 트래픽 량 등을 다양하게 고려하여 해당 무선단말 가입자의 이동통신 네트워크 사용 비용을 3rd Party 인터넷서비스 제공사업자가 대신 지불하는 스폰서 서비스를 위한 IMS 기반의 이동통신 네트워크 시스템을 제공하는 것을 목적으로 한다.
또한 본 발명은, 스폰서 서비스가 제공 시, 차별화된 서비스 품질을 제공할 수 있고, 해당 서비스 품질은 해당 인터넷서비스가 개시하는 시점에서 동적으로 제어가 가능하며, 스폰서 서비스의 개시시점에서 적합하게 허용된 서비스인지 여부를 확인하여 적합하지 않은 경우에는 사전에 차단하는 작업을 지원하는 스폰서 서비스를 위한 IMS 기반의 이동통신 네트워크 시스템을 제공하는 것을 목적으로 한다.
아울러 본 발명은, 특정 지역 등에서 특정 인터넷서비스 혹은 콘텐트에 대한 요구 급증으로 인한 부하가 발생하거나 해당 트래픽의 전송 급증으로 인하여 송신 지연이 발생 시, 동적으로 인터넷서비스의 콘텐트/서비스가 이동통신 네트워크 사업자의 네트워크 안으로 이동하여, 무선단말에 가장 가까운 곳에서 해당 서비스를 제공하는 스폰서 서비스를 위한 IMS 기반의 이동통신 네트워크 시스템을 제공하는 것을 목적으로 한다.
상기와 같은 문제점을 해결하기 위한 본 발명의 IMS 기반의 이동통신 네트워크에서 인터넷 서비스 제공 서버(Internet Service Provider Server)가 단말의 이동통신 사용 요금을 대납할 수 있는 스폰서 서비스(Sponsored Service) 제공하는 방법은, 상기 스폰서 서비스를 제공하기 위하여 상기 단말에 포함된 스폰서 서비스 클라이언트(Sponsored Service and Connectivity Client)가 상기 스폰서 서비스를 제공하기 위한 스폰서 서비스 서버(Sponsored Service Sever)에 상기 스폰서 서비스 개시 요청 메시지를 전송하는 단계; 상기 스폰서 서비스 서버가 상기 개시 요청 메시지 수신 후, 상기 스폰서 서비스의 유효 여부를 판단하는 단계; 상기 스폰서 서비스 서버가 상기 스폰서 서비스가 유효하다고 판단하는 경우, 스폰서 서비스 개시 승인 메시지를 상기 스폰서 서비스 클라이언트로 전송하는 단계; 상기 스폰서 서비스 클라이언트와 상기 인터넷 서비스 제공 서버 간 스폰서 서비스 세션을 생성하는 단계; 상기 스폰서 서비스 클라이언트의 상기 스폰서 서비스 종료 요청 시, 상기 스폰서 서비스 서버가 과금 정보를 생성하고 AAA 서버(Authentication/Authorization/ Accounting Sever)로 상기 과금정보를 전송하는 단계; 및 상기 스폰서 서비스 세션을 종료하는 단계를 포함하는 것을 특징으로 한다.
한편, 본 발명의 IMS 기반의 이동통신 네트워크에서 인터넷 서비스 제공 서버(Internet Service Provider Server)가 단말의 이동통신 사용 요금을 대납할 수 있는 스폰서 서비스(Sponsored Service) 제공 시스템은, 상기 스폰서 서비스를 제공하기 위하여 상기 단말에 포함된 스폰서 서비스 클라이언트(Sponsored Service and Connectivity Client), 상기 스폰서 서비스를 제공하기 위한 스폰서 서비스 서버(Sponsored Service Sever), 상기 인터넷 서비스 제공 서버 및 AAA 서버(Authentication/Authorization/ Accounting Sever)를 포함하고, 상기 스폰서 서비스 클라이언트(Sponsored Service and Connectivity Client)가 상기 스폰서 서비스 서버(Sponsored Service Sever)에 상기 스폰서 서비스 개시 요청 메시지를 전송하는 단계; 상기 스폰서 서비스 서버가 상기 개시 요청 메시지 수신 후, 상기 스폰서 서비스의 유효 여부를 판단하는 단계; 상기 스폰서 서비스 서버가 상기 스폰서 서비스가 유효하다고 판단하는 경우, 스폰서 서비스 개시 승인 메시지를 상기 스폰서 서비스 클라이언트로 전송하는 단계; 상기 스폰서 서비스 클라이언트와 상기 인터넷 서비스 제공 서버 간 스폰서 서비스 세션을 생성하는 단계; 상기 스폰서 서비스 클라이언트의 상기 스폰서 서비스 종료 요청 시, 상기 스폰서 서비스 서버가 과금 정보를 생성하고 AAA 서버(Authentication/Authorization/ Accounting Sever)로 상기 과금정보를 전송하는 단계; 및 상기 스폰서 서비스 세션을 종료하는 단계를 포함하는 것을 특징으로 한다.
본 발명에 따르면, 무선단말가입자의 이동통신 네트워크 사용 비용을 3rd Party 인터넷서비스 제공사업자가 대신 지불하는 스폰서 서비스를 제공할 수 있다. 스폰서 서비스가 제공 시, 차별화된 서비스 품질을 제공할 수 있고, 해당 서비스 품질은 해당 인터넷서비스가 개시하는 시점에서 동적으로 제어가 가능하다. 또한, 스폰서 서비스의 개시시점에서 적합하게 허용된 서비스인지 여부를 확인하여 적합하지 않은 경우에는 사전에 차단하는 작업을 지원할 수도 있다.
아울러 인터넷 서비스를 활용하는 무선단말 가입자에게 빠른 응답시간과 무선에 최적화된 서비스 품질을 제공하고, 인터넷서비스 제공사업자 역시 순간적인 부하 발생 시, 이동통신 네트워크 사업자의 처리능력 및 통신능력을 임시로 사용함으로써, 순간적인 부하에 따른 추가 증설 등의 비용 부담을 줄일 수 있어 서비스 사용자들에게 만족스러운 서비스를 제공할 수도 있다.
도 1은 종래 기술에 따른 이동통신 네트워크에서 인터넷서비스 개념을 도시하는 도면이다.
도 2는 본 발명의 실시예에 따른 이동통신 네트워크에서 인터넷서비스 개념을 도시하는 도면이다.
도 3은 본 발명의 실시예에 따른 이동통신 네트워크 접속 시, SSC 서버 정보 취득 과정을 도시하는 도면이다.
도 4는 본 발명의 실시예에 따른 무선 단말의 내부 구조를 도시하는 도면이다.
도 5는 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 승인 절차를 도시하는 순서도이다.
도 6은 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 해제 절차를 도시하는 순서도이다.
도 7은 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 승인 거절 절차를 도시하는 순서도이다.
도 8은 본 발명의 다른 실시예에 따른 어플리케이션 스폰서 서비스의 승인 거절 절차를 도시하는 순서도이다.
도 9는 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 간략화된 승인 절차를 도시하는 순서도이다.
도 10은 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 간략화된 해제 절차를 도시하는 순서도이다.
도 11은 본 발명의 실시예에 따른 통신 스폰서 서비스의 승인 절차를 도시하는 순서도이다.
도 12는 본 발명의 실시예에 따른 통신 스폰서 서비스의 간략화된 승인 절차를 도시하는 순서도이다.
도 13은 본 발명의 실시예에 따른 컨텐츠 전달 스폰서 서비스 절차를 도시하는 순서도이다.
도 14는 본 발명의 실시예에 따른 지능형 처리 및 컨텐츠 전송 스폰서 서비스의 개념을 도시하는 순서도이다.
도 15는 본 발명의 실시예에 따른 이동통신 네트워크로의 컨텐츠 이동 절차를 도시하는 순서도이다.
도 16은 본 발명의 실시예에 따른 이동통신 네트워크 내의 컨텐츠를 활용한 인터넷 서비스 절차를 도시하는 순서도이다.
도 17은 본 발명의 실시예에 따른 이동통신 네트워크 내의 컨텐츠 제거 절차를 도시하는 순서도이다.
도 18은 본 발명의 실시예에 따른 처리 및 컨텐츠 스폰서 서비스 절차를 도시하는 순서도이다.
도 19는 이동통신 네트워크로의 처리부/컨텐츠 이동 절차를 도시하는 순서도이다.
도 20은 이동통신 네트워크 내의 처리부/컨텐츠를 활용한 인터넷 서비스 절차를 도시하는 순서도이다.
도 21은 이동통신 네트워크 내의 처리부/컨텐츠 제거 절차를 도시하는 순서도이다.
도 22는 SSC 서버의 어플리케이션 스폰서 서비스 승인 절차를 도시하는 순서도이다.
도 23은 SSC 서버의 어플리케이션 스폰서 서비스의 QoS/통계정보 설정 절차를 도시하는 순서도이다.
도 24는 SSC 서버의 과금 정보 생성 및 전달 절차를 도시하는 순서도이다.
도 25는 SSC 서버의 통신 스폰서 서비스 승인 절차를 도시하는 순서도이다.
도 26은 ISP 서버의 지능형 처리 및 컨텐츠 전송 스폰서 서비스 절차를 도시하는 순서도이다.
본 발명에서 스폰서 서비스(Sponsored Service)란, IMS에 기반하여 인터넷서비스의 이동통신 네트워크 사용 비용을 무선단말가입자 대신 인터넷서비스 제공사업자가 지불하는 서비스를 의미한다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예들을 상세히 설명한다. 이 때, 첨부된 도면에서 동일한 구성 요소는 가능한 동일한 부호로 나타내고 있음에 유의해야 한다. 또한 본 발명의 요지를 흐리게 할 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략할 것이다.
우선, 도 2는 본 발명의 실시예에 따른 이동통신 네트워크에서 인터넷서비스 개념을 도시하는 도면이다.
본 발명의 실시예에 따른 이동통신 네트워크에서 인터넷서비스는 종래 기술과 달리 IMS 기반의 서비스가 아닌 인터넷서비스의 제공을 위해서도 인터넷서비스 제공사업자의 인터넷서비스 서버(270)와 무선단말 간에 IMS가 개입하게 된다. 즉 인터넷서비스에 대해서도 IMS 코어 네트워크를 통한 제어 측면에서의 인터페이스가 동작하게 된다.
본 발명의 실시예에 따르면, 스폰서 서비스를 위하여 무선단말은 스폰서 서비스 및 연결 클라이언트를 포함한다. IMS 코어 네트워크 내부에는 SSC 서버(230)를 포함하고, 이는 IMS의 중앙교환장치인 CSCF(Call Session Control Function)에 연결하는 어플리케이션 서버(AS)로 정의한다. 또한, 인터넷서비스제공사업자의 인터넷서비스 서버(270)에도 IMS 클라이언트 기능이 적용될 수 있다. 마지막으로 SSC 클라이언트(220), SSC 서버(230), 인터넷서비스 서버(270) 간에 제어 인터페이스가 새롭게 정의되며, SSC 서버(230)와 PCRF/PGW(280/290)와도 새로운 제어 인터페이스가 정의된다.
본 발명의 구체적인 설명에 앞서 개략적으로 기술하면 다음과 같다.
첫째, 본 발명의 일 실시예에 따른면, 무선단말의 운영체제, 디바이스 드라이버 또는 (보안이 보장되는) 기본 프로그램으로서 단말에 설치된 SSC 클라이언트(220)가 있으며, 해당 SSC 클라이언트(220)는 상위 어플리케이션에게 API를 제공한다. 해당 API는 스폰서 서비스(Sponsored Service)로서 동작하고자 하는 어플리케이션에 의하여 호출되며, 해당 API를 통하여 무선단말의 어플리케이션은 SSC 서버(230)를 통하여 유효한 스폰서 서비스인지 여부를 해당 어플리케이션의 구동 시에 확인 받을 수 있다. 따라서, 본 발명에서는 모든 인터넷서비스의 식별은 고려하지 않지만, 스폰서 서비스로서 동작하는 경우에는 해당 API를 호출하도록 함으로서 인터넷서비스임에도 구동 여부를 알 수 있게 된다.
둘째, 본 발명의 일 실시예에 따르면, 스폰서 서비스로서 동작하고 싶은 어플리케이션은 SSC 클라이언트(220)의 API를 호출하게 된다. 해당 API의 기능은 어플리케이션에 투명하고 독립적으로 IMS 제어 메시지를 생성한 후, IMS 코어 네트워크를 통하여 해당 스폰서 서비스가 유효한지 여부에 대한 승인을 받는 것이다. 이를 위하여 SSC 클라이언트(220)에서 만들어진 스폰서 서비스 승인 요청 메시지는 CSCF(260)를 경유하여 SSC 서버(230)에 도착하게 되고, SSC 서버(230)가 유효하다고 판단하는 경우, 바로 무선단말의 SSC 클라이언트(220)에 승인 허락을 하거나, 혹은 추가적으로 인터넷서비스 제공사업자의 인터넷 서비스 서버로 다시 IMS 메시지를 전송하여 추가적인 인터넷제공사업자의 승인을 동적으로 받을 수 있도록 한다. 따라서, 스폰서 서비스는 동적으로 해당 서비스의 유효 여부를 이동통신 네트워크 사업자의 IMS 코어 네트워크와 인터넷서비스 제공사업자로부터 검증 받을 수 있다.
셋째, 종래 이동통신 네트워크는 원래 IMS 서비스에 대해서만 QoS를 보장할 수 있어 3rd Party 인터넷서비스 제공사업자의 인터넷서비스에 대해서는 Qos를 보장할 수 없었다. 하지만, 본 발명의 일 실시예에 따른 스폰서 서비스는 IMS를 기반으로 제공되므로 QoS를 보장받을 수 있다. SSC 서버(230)는 인터넷서비스 제공사업자가 제공하고자 하는 인터넷 서비스의 QoS 정보를 사전에 인터넷서비스 제공사업자로부터 받아 저장하게 된다. 해당 QoS 정보는 SSC 서버(230)의 스폰서 서비스 승인 확인 시점에 이동통신 네트워크의 게이트웨이 장치로 전달하게 되어, 이후 스폰서 서비스에 대한 트래픽이 이동통신 네트워크에 유입되는 경우에 대해서 IMS와 동일한 QoS 보장을 지원할 수 있다.
넷째, 본 발명의 일 실시예에 따르면, 추가적으로 동적으로 변경되는 QoS를 인터넷서비스 제공사업자가 본인의 인터넷 서비스에 대해서 제공하고자 한다면, IMS 기반 제어 메시지에 대한 응답(즉, 스폰서 서비스에 대한 승인을 위한 IMS 메시지 전송)시에 새롭게 적용되기를 바라는 QoS 정보를 해당 메시지에 넣어서 보냄으로써, 해당 신규 정보를 수신한 SSC 서버(230)가 이전 QoS 정보 대신 신규 QoS 정보를 이동통신 네트워크의 게이트웨이로 전달하는 것이 가능하다.
다섯째, 본 발명의 실시예에 따르면, 다수의 무선단말들이 특정 지역에서 특정 인터넷서비스를 집중적으로 사용함에 따라서, 동일한 서비스와 콘텐트가 특정 지역으로 전송되어야 하는 경우에는, 해당 서비스 요청 급증 지역에 인터넷서비스를 위한 콘텐트와 서비스자체를 이동시킴으로써, 네트워크의 부하를 줄이고, 무선단말가입자와 인터넷서비스 제공사업자의 품질 향상을 지원한다.
본 발명에서, 무선단말가입자는 기본적으로 이동통신 네트워크 사업자의 IMS 코어 네트워크에 가입하는 것으로 설정한다. IMS 코어 네트워크에 가입함으로서, 무선단말가입자는 IMS의 identifier (ID)를 할당받게 되며, 해당 ID를 활용하여 스폰서 서비스를 제공받는다. IMS에 가입 시, 명시적으로 무선단말가입자가 이동통신 네트워크 사업자의 IMS 서비스에 가입하여 ID를 부여 받는 방법도 있고, 내재적인 방법도 있다. 내재적인 방법은 이동통신 네트워크 사업자가 스마트폰, 스마트패드 등의 장치에서 동작하는 어플리케이션을 SSC 클라이언트(220)(230)의 기능을 호출할 수 있도록 개발하고, 해당 어플리케이션이 구동하면, 무선단말가입자가 스폰서 서비스를 앞으로 사용할 것인지 아닌지를 결정하게 한다. 앞으로 스폰서 서비스를 사용하고자 한다면, 해당 어플리케이션을 통해서 본인의 ID를 만들게 된다. 물론 ID에 대한 인증을 위한 패스워드도 같이 만들게 된다. 이는 사용자가 IMS 서비스 유무를 모르게, SSC 클라이언트(220)의 기능을 호출하여 IMS 코어 네트워크와의 통신을 수행함으로 가능해 진다. 따라서, 후자의 경우는 사용자가 단지 스폰서 서비스를 받을 수 있는 자격을 얻을 수 있도록 ID를 생성한 것으로 인식하게 되며, IMS 코어 네트워크에 IMS ID가 생긴 것인지에 대한 여부는 편리성을 위하여 가릴 수 있다. 이후, 무선단말가입자가 스폰서 서비스를 받기 위하여 생성한 IMS ID를 Sponsorship ID로 칭하도록 한다. 따라서 무선단말가입자는 다음의 정보를 생성하고 관리하게 된다.
{ Sponsorship ID & Password }
스폰서 서비스를 제공하는 인터넷서비스 제공사업자의 경우, 사전에 SSC 서버(230)에 본인을 등록하는 과정을 거치도록 한다. 즉, 온라인 혹은 오프라인 등록과정을 통하여 인터넷서비스 제공사업자는 본인이 사용할 사업자 식별자(ISP ID)와 패스워드를 발급받고, 추가적으로 본인이 스폰서 서비스로 제공하고자 하는 서비스의 별도 식별자가 필요한 경우는 개별 서비스에 대한 개별 ID(Service IDs)를 발급받도록 한다. 그리고 스폰서 서비스를 제공한 후 해당 스폰서 서비스에 대한 비용을 지불하게 되는 계좌번호(Account Info)도 등록한다. Sponsored Service Types는 인터넷서비스 제공사업자가 이동통신 네트워크 사업자를 통해서 받고자 하는 스폰서 서비스의 타입을 의미한다. 이는 아래에서 구체적으로 설명할 1)어플리케이션 스폰서 서비스, 2)통신 스폰서 서비스 또는 3)지능형 처리 및 컨텐츠 전송 스폰서 서비스 중 어느 하나를 의미하는 것이다. 본 발명의 실시예에 따르면, 1)의 서비스를 지원하면 0x0001, 2)를 지원하면 0x0010, 3)을 지원하면 0x0100으로 하고, Sponsored Service Types는 1)~3)의 값을 OR 하여 저장하는 것과 같이 표현할 수 있다. 따라서 인터넷서비스 제공사업자가 본인을 위하여 SSC 서버(230)에 등록하는 가장 기본이 되는 정보는 다음과 같다. 해당 정보는 SSC 서버(230)에서 각 인터넷서비스 제공사업자별로 관리되며, 마찬가지로 해당 인터넷서비스 제공사업자도 본인의 정보를 저장/관리해야 한다.
{ ISP ID & Password, Account Info, Sponsored Service Types,
Service ID#1, … Service #N }
Service ID의 경우는 IMS 세션을 만들 수 있는 착신지 주소가 될 수 있는 IMS ID가 될 수도 있고, IMS 제어 메시지 안에 내부에 편입되는 정보로서 IMS ID의 형태를 갖지 않을 수도 있다.
Service ID로 식별되는 개별 서비스들은 인터넷서비스 제공사업자가 희망하는 경우에 이동통신 네트워크 안에서 차별화된 QoS를 제공할 수 있다. 이를 위해서는 Service ID별로 추가적인 QoS 정보를 인터넷서비스 제공사업자가 이동통신 네트워크 사업자에게 요청하여야 한다. 이에 대한 예시는 다음과 같다.
{ Service ID#N : Minimum Bandwidth, Maximum Bandwidth, Delay, Jitter }
각각의 스폰서 서비스는 상기 QoS 파라메타를 독립적으로 가질수 있다.
QoS에 대한 정보에 추가적으로 해당 Service ID별로 조건적인 스폰서 서비스 지원 규칙을 정의할 수 있다. 즉 특정 날짜 및 시간, 특정 장소, 특정 가입자, 특정 단말타입 들에 대해서만 해당 스폰서 서비스가 지원될 수 있도록 제약을 두는 것이다. 이를 위하여 SSC 서버에서는 인터넷서비스제공사업자로부터 각 스폰서 서비스 별로 다음의 정보를 받아 관리할 수 있어야 한다. 하기 사항은 예시이며, 추가적인 사항의 정의도 가능하다.
{ Service ID#N : (Allowed) Time & Date, Region, Subscribers, Terminal Types }
상기 정보에 추가적으로 각 ISP ID별로, 스폰서 서비스 개시에 대한 요청이 발생하는 경우, 인터넷서비스 제공사업자 자체도 해당 스폰서 서비스의 개시에 대해서 승인을 하고자 하는지 아닌지에 대한 플래그 정보를 다음과 같이 갖는다. 해당 flag가 yes인 경우에 대해서는, 스폰서 서비스가 무선단말에서 요청될 때 마다 해당 인터넷서비스 제공사업자도 합법적인 요청에 대한 승인 과정에 직접 차여하게 된다. 만약 flag가 no라면, 무선단말로부터의 승인 요청은 매번 인터넷서비스 제공사업자까지 전달되지 않고 SSC 서버(230) 레벨에서 처리되게 된다.
{ ISP ID : SponsoredService_AuthCapability_Flag [= Yes or No] }
본 발명의 설명은 구체적인 동작 시나리오를 기준으로 수행하도록 한다. 앞서 설명한 것처럼, 스폰서 서비스를 제공하고자 하는 인터넷서비스 제공사업자는 SSC 서버에 본인에 대한 정보와 본인이 제공할 구체적인 서비스에 대한 정보를 등록한다. 그리고, 스폰서 서비스를 사용하고자 하는 무선단말가입자도 SSC 클라이언트(220)를 통하여 IMS ID로 만들어진 Sponsorship ID를 등록하여야 한다. 아래의 설명은 상기 두 가지 작업을 이후의 무선단말과 인터넷서비스 제공사업자 사이의 작업을 나타낸다.
도 3은 본 발명의 실시예에 따른 이동통신 네트워크 접속 시, SSC 서버 정보 취득 과정을 도시하는 도면이다.
먼저, 무선단말은 이동통신 네트워크에 접속하게 되면, 자신의 IP주소를 획득하게 된다. 본 발명의 실시예에 따르면, 도 3에 도시하는 바와 같이, 이동통신 네트워크에 접속한 무선단말이 본인이 사용할 IP 주소 외에 추가적으로 SSC 서버 정보를 획득한다.
본 발명에서는 Long Term Evolution (LTE) 네트워크를 기본으로 설명한다. 따라서, 무선단말에 대한 IP주소는 PDN Gateway (PGW)가 할당하게 된다. 본 발명의 실시예에서 SSC 서버는 이동통신 네트워크 내부에서 하나일 수도 있지만, 복수로 존재할 수 도 있다. 하나만 존재하는 경우는 하나의 서버가 전체 이동통신 네트워크 영역을 관리하는 것이며, 복수인 경우는 이동통신 네트워크를 지역적으로 구분한 후, 각각의 지역에 독립적인 SSC 서버를 운영할 수도 있다. 따라서, 무선단말은 최초로 이동통신 네트워크에 진입하여 IP주소를 할당받는 과정에서 해당 이동통신 네트워크를 관리하는 SSC 서버의 식별자 혹은 IP주소를 받는다. SSC 서버의 식별자는 IMS ID의 형태를 갖는 것을 기본으로 한다.
또 다른 실시예에 따르면, 무선단말이 특정 사업자에 종속된 경우, 단말 내부의 SSC 클라이언트(220)에 URI (Uniform Resource Identifier) 타입으로 미리 해당 이동통신 네트워크에서의 SSC 서버 주소를 심어 놓는 것도 가능하다. 이 경우, 이동통신 네트워크 사업자가 단일 SSC 서버를 운용하는 경우, 해당 URI에 대응하는 단일의 IP주소가 존재하며, 복수의 SSC 서버를 운용하는 경우는, 해당 URI에 대응하는 복수의 IP주소가 존재할 수 있다. 후자의 경우, 이동통신 네트워크에 접속한 무선단말이 기 설정된 SSC 서버의 URI를 DNS(Domain Name Service) 등을 통해 IP주소로 변환하기 위하여, 이동통신 네트워크로 전송하게 된다. 이를 수신한 이동통신 네트워크는 해당 단말이 요청을 보내온 이동통신 네트워크의 지역을 기반으로 하여, 해당 지역을 관장하는 SSC 서버의 IP주소를 전달할 수 있다.
도 4는 본 발명의 실시예에 따른 무선 단말의 내부 구조를 도시하는 도면이다.
도 4에서 도시하는 바와 같이, SSC 클라이언트(220)는 IMS Client 기능을 내재하고 있으며, 이를 활용하는 어플리케이션은 API를 통해서 해당 기능을 구동한다. 어플리케이션은 SSC 클라이언트(220)가 IMS 프로토콜인지를 알 필요가 없으며, 단순화된 명령을 통하여 IMS 연결에 기반한 스폰서 서비스를 경험하게 된다.
본 발명의 실시예에 따르면, 어플리케이션은 스폰서 서비스의 시작시점에서 다음의 명령을 수행한다.
Sponsorship_Auth_Request( targetISPaddress, sponsorship_option );
상기 명령은 targetISPaddress로 대표되는 스폰서 서비스의 상대편 주소로서, 앞서의 ISP ID 혹은 Service ID로 나타내어 진다. 혹은 targetISPaddress는 인터넷서비스 서버의 IP주소로 나타내고, sponsorship_option에 ISP ID 혹은 Service ID를 기입하는 것도 가능하다.
유효한 스폰서 서비스에 대한 요청으로 SSC 클라이언트(220)는 다음의 응답을 준다.
Sponsorship_Auth_Response( "OK", reasonCode );
이는 성공적으로 스폰서 서비스 사용에 대한 승인이 이루어진 것이다. reasonCode는 별도의 추가적인 정보를 SSC 클라이언트(220)에서 어플리케이션에게 전달할 필요가 있는 경우 사용한다. 반대로 실패하는 경우는 다음의 응답을 어플리케이션에게 전달한다.
Sponsorship_Auth_Response( "NOK", reasonCode );
SSC 클라이언트(220)의 구현에 따라서, 운영체제 개발사가 운영체제 내부에 처음부터 구현하는 경우가 있고, 이동통신 네트워크 사업자가 Software Development Kit (SDK) 혹은 Device-driver Development Kit (DDK)의 형태로 인터넷서비스 제공사업자에 제공하여, 해당 인터넷서비스 제공사업자들이 자신들이 만들어서 배포하는 어플리케이션내부에 삽입하여 배포할 수 도 있다. 아울러 이동통신 네트워크 사업자가 운영체제 위에서 동작하는 추가프로그램으로서 배포하는 것도 가능하다.
상기 기재한 바와 같이 본 발명은 1)어플리케이션 스폰서 서비스, 2)통신 스폰서 서비스 또는 3)지능형 처리 및 컨텐츠 전송 스폰서 서비스로 구분할 수 있다. 아래에서 각각의 구체적인 동작을 설명한다.
먼저 어플리케이션 스폰서 서비스에 대한 서비스 개시 절차가 도 5에 나타나 있다. 도 5는 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 승인 절차를 도시하는 순서도이다.
무선단말의 스폰서 서비스를 지원하는 어플리케이션(210)은 SSC 클라이언트(220)로부터 API를 호출하고 API는 스폰서 서비스 개시를 SSC 클라이언트(220)에게 요청한다. SSC 클라이언트(220)는 스폰서 서비스 개시 요청이 있는 경우, 505단계에서 IMS 메시지인 스폰서 서비스 개시 요청 메시지 CSCF로 전송하게 된다. 도면에서 스폰서 서비스 개시 요청 메시지는 Invite 메시지로 표시된다. 본 발명의 실시예에 따르면, IMS 메시지의 수신지 주소가 인터넷서비스 제공사업자가 초기 등록한 ISP ID와 Service ID중에 Service ID이며, 해당 Service ID가 IMS ID 형태로 만들어진 것이라고 설정하여 설명한다. 물론, 상기에서 기재한 바와 같이 ISP ID 혹은 IP 주소 등 다양한 조합이 가능하다.
해당 Invite 메시지는 수신지를 인터넷서비스 제공사업자의 Service ID로 함과 동시에 Invite 메시지의 via 필드에 SSC 서버(230)의 ID(혹은 주소, 이후 ID로 통일하여 설명함)를 반드시 삽입하도록 한다. 이는 스폰서 서비스의 경우는 반드시 SSC 서버를 통해서 Invite 메시지가 전달되어야 하는 것을 의미한다. 따라서, 510단계에서 CSCF는 Invite 메시지를 SSC 서버로 전송한다.
SSC 서버(230)는 Invite 메시지 수신 후, 515단계로 진행하여, AAA 서버(250)로 스폰서 서비스 정보를 포함하는 ISP 및 무선 단말 정보를 문의하여 획득한다.
SSC 서버(230)는 520단계에서 무선단말(220)로부터 Invite 메시지를 수신한 SSC 서버는 내부의 데이타 베이스를 검색하여 수신지로 지정된 인터넷서비스 제공사업자의 정보가 올바르고 유효한 스폰서로서 등록이 되어 있는지를 일차적으로 검사한다. 유효한 스폰서에 대한 스폰서 서비스 사용 요청이라면, 다시 해당 스폰서 서비스의 승인에 대한 추가 조건이 있는지를 검사하여, 해당 추가 조건이 있다면, 현재 요청을 기준으로 추가 조건에 부합하는지를 판단한다. 추가조건은 앞서 언급한 스폰서 서비스가 승인되는 날짜/시간, 장소, 단말 타입 등을 의미한다. 날짜/시간에 대한 정보는 현재 시각을 기준으로 판단하며, 장소는 단말의 IP주소를 기본으로 하여, 광역의 주소를 점검하며, 인터넷서비스 제공사업자의 요청이 있고 무선단말가입자의 승인이 있으면 현재 단말의 위치를 해당 무선단말가입자의 정보를 기반으로 추출하여 평가할 수 있다. 마찬가지로 해당 단말의 타입도 해당 무선단말가입자의 정보를 기반으로하여 AAA 서버(250) 혹은 Device Management (DM) 서버 등에서 추출하여 판단할 수 있다.
SSC 서버(230)가 상기 조건들을 확인하여 문제가 없으면, 마지막으로 해당 스폰서 서비스를 지원하는 인터넷서비스 제공사업자의 SponsoredService _AuthCapability_Flag를 확인한다. 해당 flag가 yes인 경우, 525단계로 진행하여 Invite 메시지를 CSCF(260)로 전송하고 530 단계에서 CSCF(260)는 Invite 메시지를 ISP 서버(270)로 전송한다. Invite 메시지를 수신한 인터넷서비스 제공사업자는 스폰서 서비스 개시 요청을 인터넷서비스 제공사업자가 직접 확인한다.
스폰서 서비스 개시 요청을 인터넷서비스 제공사업자가 직접 확인하는 경우는 각각 다음과 같다. 먼저, 인터넷서비스 사업자가 동적으로 스폰서 서비스 지원여부를 판단하는 경우, 다음으로 인터넷서비스 사업자가 무선단말에 대한 통계정보를 직접 갖고 싶은 경우, 마지막으로 인터넷서비스 사업자가 동적으로 스폰서 서비스의 QoS를 조정하고자 하는 경우, 스폰서 서비스 개시 요청을 인터넷서비스 제공사업자가 직접 확인할 수 있다. 이때 Invite 메시지의 수신지 주소는 인터넷서비스 제공사업자의 ISP ID 혹은 Service ID 혹은 앞서 정보를 내부 데이타로 담은 후 IP 주소를 사용하는 경우이다.
535단계에서 인터넷서비스 제공사업자가 유효한 스폰서에 대한 스폰서 서비스 사용 요청인지 여부를 판단한다. 인터넷서비스 제공사업자가 유효하다고 판단하는 경우, 540 단계로 진행하여 ISP 서버(270)는 개시 승인 메시지를 CSCF(260)으로 전송한다. 도면에서 개시 승인 메시지는 200 OK메시지로 표시된다. 이때, 동적으로 QoS를 바꾸고자 하는 경우는, Sponsored Service에 대한 QoS 정보를 부가정보로서, 200 OK메시지 안에 담아 전송할 수 있다.
CSCF(260)는 545단계에서 수신한 200 OK 메시지를 SSC 서버(230)로 전달한다. Qos 정보가 포함된 경우, SSC 서버(230)는 자신이 가지고 있던 Qos 정보를 수신한 Qos 정보를 업데이트한다. SSC 서버(230)는 550단계에서 200 OK메시지를 확인하여 스폰서 서비스가 유효함을 확인하고 555단계로 진행하여 CSCF(260)로 개시 승인 메시지를 전송하고 560단계에서 QoS정보와 Policy를 PGW/PCRF로 전송한다. 그 후 CSCF(260)는 565단계에서 개시 승인 메시지를 SSC 클라이언트(220)로 전송한다.
SSC 클라이언트(220)는 570단계에서 수신 확인 메시지를 CSCF(260)으로 전송한다. 도면에서 수신 확인 메시지는 ACK 메시지로 표시된다. 580단계에서 CSCF(260)는 ACK 메시지를 SSC 서버(230)으로 전송하고, 585단계에서 SSC 서버(230)는 ACK 메시지 메시지를 CSCF(260)으로 전송하며 590단계에서 CSCF(260)는 ACK 메시지 메시지를 ISP 서버(270)로 전송한다.
SSC 클라이언트(220)는 570단계에서 ACK 메시지 메시지를 CSCF(260)으로 전송 후 스폰서 서비스 연결 성공에 대한 사항을 자체적인 Graphic User Interface (GUI)로써 알려준다. 이는 어플리케이션과 독립적으로 이루어지며, 사용자가 안심하고 스폰서 서비스를 사용할 수 있도록 하는 체제이다.
ISP 서버(270)가 ACK 메시지 확인 후, 595단계에서 어플리케이션(210)과 상기 ISP 서버(270) 간 스폰서 서비스 세션이 생성된다.
도 6은 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 해제 절차를 도시하는 순서도이다.
무선단말사용자가 스폰서 서비스를 종료하는 경우에는 도 6의 절차가 이루어 진다. 어플리케이션(210)은 스폰서 서비스의 종료를 위한 Sponsorship_Release_Request()를 API를 통해서 호출한다. 이를 수신한 SSC 클라이언트(220)는 605단계에서 종료 요청 메시지를 CSCF(260)로 전송한다. 종료 요청 메시지는 IMS 메세지로서 도면에 Bye 메시지로 표시한다. 610단계에서 CSCF는 SSC 서버로 Bye 메시지를 전송한다.
이를 수신한 SSC 서버(230)는 먼저 해당 서비스의 종료를 인식한 후, 615단계로 진행하여 PGW(280)에서 해당 스폰서 서비스가 사용한 송수신 트래픽 량 등의 정보를 취합한다. SSC 서버(230)는 620단계에서 취합돤 정보를 과금서버가 이해할 수 있는 Call Detail Recording (CDR)의 형태로 만들어서 AAA (Authentication/Authorization/ Accounting) 서버(250)에게 전달한다. 그 후, SSC 서버(230)는 625단계로 진행하여 Bye 메시지를 CSCF로 전송하고, 630단계에서 CSCF는 ISP 서버로 Bye 메시지를 전송한다.
이때 SSC 서버(230)는 앞서 PGW(280)를 통하여 수신한 트래픽 량 등 과금에 대한 정보를 가공하여 사용자 들이 이해하기 쉬운 형태로 만든후, Bye 메시지에 포함시켜서 인터넷서비스 제공사업자에게 전달하게 된다. 이를 통하여 인터넷서비스제공사업자는 각각의 스폰서 서비스 세션이 종료될 때 마다, 동적으로 바로바로 과금에 대한 통계 정보를 확인할 수 있게 된다.
인터넷서비스 제공사업자는 635단계에서 해당 Bye 메시지에 대한 응답으로 종료 승인 메시지를 CSCF로 전송한다. 종료 승인 메시지는 도면에서 200 OK 메시지로 표시된다. 640단계에서 CSCF는 200 OK 메시지를 SSC 서버(230)로 전송하고, 645단계에서 SSC 서버(230)는 200 OK 메시지를 CSCF(260)로 전송하고 650단계에서 CSCF는 200 OK 메시지를 SSC 클라이언트(220)로 전송한다. 이때, 200 OK 메시지는 Bye 메시지와 마찬가지로 과금에 대한 통계정보를 포함한다.
이를 수신한 SSC 클라이언트(220)는 655단계에서 해당 과금 정보를 무선단말사용자에 보여줌으로서, 서비스 종료 시 본인이 활용한 스폰서 서비스 비용이 얼마였는지를 바로 바로 확인할 수 있도록 한다. 마지막으로 SSC 클라이언트(220)는Sponsorship_Release_Response() 응답을 API를 통해서 어플리케이션에게 전달한다.
도 7은 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 승인 거절 절차를 도시하는 순서도이고 도 8은 본 발명의 다른 실시예에 따른 어플리케이션 스폰서 서비스의 승인 거절 절차를 도시하는 순서도이다.
도 7은 SSC 서버(230)가 스폰서 서비스의 승인을 불허한 경우이고, 도 8은 인터넷서비스 제공사업자의 서버(260)가 스폰서 서비스의 승인을 불허한 경우이다. 이는 각각의 서버가 해당 시점에서 스폰서 서비스의 유효성을 판단하는 과정에서, 유효하지 않다고 판단되는 경우 이를 거절함으로서, 단말에 승인 거절 메시지를 전달하는 경우이다. 이 경우, 무선단말에서는 해당 스폰서 서비스의 사용이 불가능하다.
도 7의 경우, 무선단말의 스폰서 서비스를 지원하는 어플리케이션(210)은 SSC 클라이언트(220)로부터 API를 호출하고 API는 스폰서 서비스 개시를 SSC 클라이언트(220)에게 요청한다. SSC 클라이언트(220)는 스폰서 서비스 개시 요청이 있는 경우, 710단계에서 IMS 메시지인 스폰서 서비스 개시 요청 메시지 CSCF로 전송하게 된다. 도면에서 스폰서 서비스 개시 요청 메시지는 Invite 메시지로 표시된다. 그 후, 720단계에서 CSCF는 Invite 메시지를 SSC 서버로 전송한다.
SSC 서버(230)는 Invite 메시지 수신 후, 730단계로 진행하여, AAA 서버(250)로 스폰서 서비스 정보를 포함하는 ISP 및 무선 단말 정보를 문의하여 획득한다.
SSC 서버(230)는 740단계에서 무선단말(220)로부터 Invite 메시지를 수신한 SSC 서버(230)는 내부의 데이타 베이스를 검색하여 수신지로 지정된 인터넷서비스 제공사업자의 정보가 올바르고 유효한 스폰서로서 등록이 되어 있는지를 일차적으로 검사한다. 이 때, SSC 서버(230)가 유효하지 않은 스폰서에 대한 스폰서 서비스 사용 요청이라고 판단하는 경우 750단계로 진행하여 CSCF(260)로 승인 거절 메시지를 전송한다. 승인 거절 메시지는 도면에서 488 Reject 메시지로 표시된다.
CSCF(260)는 760단계에서 수신한 488 Reject 메시지를 SSC 클라이언트(220)로 전송한다. 그 후, SSC 클라이언트(220)는 770단계에서 스폰서 서비스 연결 실패에 대한 사항을 자체적인 Graphic User Interface (GUI)로써 알려준다. 마지막으로, SSC 클라이언트(220)는 API를 통해 어플리케이션(210)에 스폰서 서비스 연결 실패를 전달한다.
도 8의 경우, 무선단말의 스폰서 서비스를 지원하는 어플리케이션(210)은 SSC 클라이언트(220)로부터 API를 호출하고 API는 스폰서 서비스 개시를 SSC 클라이언트(220)에게 요청한다. SSC 클라이언트(220)는 스폰서 서비스 개시 요청이 있는 경우, 805단계에서 IMS 메시지인 스폰서 서비스 개시 요청 메시지 CSCF로 전송하게 된다. 도면에서 스폰서 서비스 개시 요청 메시지는 Invite 메시지로 표시된다. 그 후, 810단계에서 CSCF는 Invite 메시지를 SSC 서버로 전송한다.
SSC 서버(230)는 Invite 메시지 수신 후, 815단계로 진행하여, AAA 서버(250)로 스폰서 서비스 정보를 포함하는 ISP 및 무선 단말 정보를 문의하여 획득한다.
SSC 서버(230)는 820단계에서 무선단말(220)로부터 Invite 메시지를 수신한 SSC 서버는 내부의 데이타 베이스를 검색하여 수신지로 지정된 인터넷서비스 제공사업자의 정보가 올바르고 유효한 스폰서로서 등록이 되어 있는지를 일차적으로 검사한다. 유효한 스폰서에 대한 스폰서 서비스 사용 요청이라면, 다시 해당 스폰서 서비스의 승인에 대한 추가 조건이 있는지를 검사하여, 해당 추가 조건이 있다면, 현재 요청을 기준으로 추가 조건에 부합하는지를 판단한다. 추가조건은 앞서 언급한 스폰서 서비스가 승인되는 날짜/시간, 장소, 단말 타입 등을 의미한다. 날짜/시간에 대한 정보는 현재 시각을 기준으로 판단하며, 장소는 단말의 IP주소를 기본으로 하여, 광역의 주소를 점검하며, 인터넷서비스 제공사업자의 요청이 있고 무선단말가입자의 승인이 있으면 현재 단말의 위치를 해당 무선단말가입자의 정보를 기반으로 추출하여 평가할 수 있다. 마찬가지로 해당 단말의 타입도 해당 무선단말가입자의 정보를 기반으로하여 AAA 서버(250) 혹은 Device Management (DM) 서버 등에서 추출하여 판단할 수 있다.
SSC 서버(230)가 상기 조건들을 확인하여 문제가 없으면, 마지막으로 해당 스폰서 서비스를 지원하는 인터넷서비스 제공사업자의 SponsoredService _AuthCapability_Flag를 확인한다. 해당 flag가 yes인 경우, 825단계로 진행하여 Invite 메시지를 CSCF(260)로 전송하고 530 단계에서 CSCF(260)는 Invite 메시지를 ISP 서버(270)로 전송한다. Invite 메시지를 수신한 인터넷서비스 제공사업자는 스폰서 서비스 개시 요청을 인터넷서비스 제공사업자가 직접 확인한다.
535단계에서 인터넷서비스 제공사업자가 유효한 스폰서에 대한 스폰서 서비스 사용 요청인지 여부를 판단한다. 인터넷서비스 제공사업자가 유효하지 않다고 판단하는 경우, 840 단계로 진행하여 ISP 서버(270)는 CSCF(260)로 승인 거절 메시지를 전송한다. 승인 거절 메시지는 도면에서 488 Reject 메시지로 표시된다.
CSCF(260)는 845단계에서 수신한 488 Reject 메시지를 SSC 서버(230)로 전달한다. SSC 서버(230)는 850단계에서 488 Reject 메시지를 확인하여 스폰서 서비스가 유효하지 않음을 확인하고 855단계로 진행하여 CSCF(260)를 경유해 860단계에서 488 Reject 메시지를 SSC 클라이언트(220)로 전송한다. 그 후, SSC 클라이언트(220)는 770단계에서 스폰서 서비스 연결 실패에 대한 사항을 자체적인 Graphic User Interface (GUI)로써 알려준다. 마지막으로, SSC 클라이언트(220)는 API를 통해 어플리케이션(210)에 스폰서 서비스 연결 실패를 전달한다.
도 5에 도시된 실시예의 경우는 인터넷서비스 제공사업자도 IMS를 이해할 수 있어야 하고, 이를 처리하는 기능이 서버에 내재되야 한다. 하지만 IMS 기능을 기존 서비스 서버에 신규로 추가하는 과정은 어려울 수 있으며, 이동통신 네트워크 및 Telecommunication 네트워크 사업자들의 기술인 IMS를 인터넷서비스제공사업자가 이해하는 것이 부담이 될 수 있다. 따라서 이를 해결하기 위한 간략화된 절차가 도 9 및 도 10에 나타나 있다.
도 9는 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 간략화된 승인 절차를 도시하는 순서도이고 도 10은 본 발명의 실시예에 따른 어플리케이션 스폰서 서비스의 간략화된 해제 절차를 도시하는 순서도이다.
도 9에 도시된 실시예는 기본적으로 앞서 도 5의 서브셋이라고 할 수 있다. 즉, 스폰서 서비스의 판단을 SSC 서버(230)에서 결정하면, 바로 무선단말에 해당 응답을 전송하는 것이다. 따라서, 도 5와의 차이점은 기능적으로 Invite 메시지의 최종 수신지가 SSC 서버(230)이고, 스폰서 서비스의 식별을 위하여 ISP ID, Service ID가 Invite 메시지의 데이타로서 SSC 서버(230)에 전달되는 점이다. 이외의 과정은 도 5와 동일하다.
구체적으로 살펴보면, 905 - 920 단계는 505 - 520 단계와 동일하다. SSC 서버(230)가 920단계에서 무선단말(220)로부터 Invite 메시지를 수신한 SSC 서버(230)는 내부의 데이타 베이스를 검색하여 수신지로 지정된 인터넷서비스 제공사업자의 정보가 올바르고 유효한 스폰서로서 등록이 되어 있는지를 검사한다. 유효한 스폰서에 대한 스폰서 서비스 사용 요청이라면, 다시 해당 스폰서 서비스의 승인에 대한 추가 조건이 있는지를 검사하여, 해당 추가 조건이 있다면, 현재 요청을 기준으로 추가 조건에 부합하는지를 판단한다. 추가조건은 앞서 언급한 스폰서 서비스가 승인되는 날짜/시간, 장소, 단말 타입 등을 의미한다. 날짜/시간에 대한 정보는 현재 시각을 기준으로 판단하며, 장소는 단말의 IP주소를 기본으로 하여, 광역의 주소를 점검하며, 인터넷서비스 제공사업자의 요청이 있고 무선단말가입자의 승인이 있으면 현재 단말의 위치를 해당 무선단말가입자의 정보를 기반으로 추출하여 평가할 수 있다. 마찬가지로 해당 단말의 타입도 해당 무선단말가입자의 정보를 기반으로하여 AAA 서버(250) 혹은 Device Management (DM) 서버 등에서 추출하여 판단할 수 있다.
SSC 서버(230)가 상기 조건들을 확인하여 문제가 없는 경우, 도 5에 도시된 실시예와 달리 해당 스폰서 서비스를 지원하는 인터넷서비스 제공사업자의 SponsoredService _AuthCapability_Flag를 확인하는 것이 아니라 925단계에서 SSC 서버(230)가 개시 승인 메시지를 CSCF(260)으로 전송한다. 그리고 SSC 서버(230)는 930단계에서 QoS정보와 Policy를 PGW/PCRF로 전송한다. 도면에서 개시 승인 메시지는 200 OK메시지로 표시된다. 이 경우, 인터넷서비스 제공사업자가 동적으로 QoS를 바꾸는 것은 불가능하다.
CSCF(260)는 수신한 200 OK 메시지를 935단계에서 SSC 클라이언트(220)로 전송한다. SSC 클라이언트(220)는 940단계에서 수신 확인 메시지를 CSCF(260)으로 전송한다. 도면에서 수신 확인 메시지는 ACK 메시지로 표시된다. 950단계에서 CSCF(260)는 ACK 메시지를 SSC 서버(230)으로 전송한다.
SSC 클라이언트(220)는 ACK 메시지 메시지를 CSCF(260)으로 전송 후, 945단계에서, 스폰서 서비스 연결 성공에 대한 사항을 자체적인 Graphic User Interface (GUI)로써 알려준다. 이는 어플리케이션과 독립적으로 이루어지며, 사용자가 안심하고 스폰서 서비스를 사용할 수 있도록 하는 체제이다.
그 후, 955단계에서 어플리케이션(210)과 상기 ISP 서버(270) 간 스폰서 서비스 세션이 생성된다.
도 6에 도시되는 연결 해제 절차에 대해서도 마찬가지로 SSC 서버(230)에서 최종 작업을 하는 것으로 고려할 수 있으며, 이에 대한 절차가 도 10에 도시된다. 도 9에서와 마찬가지로 Bye 메시지의 최종 수신지가 SSC 서버(230)이고, 스폰서 서비스의 식별을 위하여 ISP ID, Service ID가 Bye 메시지의 데이터로서 SSC 서버(230)에 전달된다. 이외의 과정은 앞서 도 6과 동일하다.
구체적으로, 605 - 620단계는 1010 - 1040단계와 동일하다. SSC 서버(230)는 1050단계에서 종료 승인 메시지를 CSCF(260)로 전송한다. 종료 승인 메시지는 도면에서 200 OK 메시지로 표시된다. 1060단계에서 CSCF(260)는 200 OK 메시지를 SSC 클라이언트(220)로 전송한다. 이때, 200 OK 메시지는 Bye 메시지와 마찬가지로 과금에 대한 통계정보를 포함한다.
이를 수신한 SSC 클라이언트(220)는 1070단계에서 해당 과금 정보를 무선단말사용자에 보여줌으로서, 서비스 종료 시 본인이 활용한 스폰서 서비스 비용이 얼마였는지를 바로 바로 확인할 수 있도록 한다. 마지막으로 SSC 클라이언트(220)는Sponsorship_Release_Response() 응답을 API를 통해서 어플리케이션에게 전달한다.
다음으로 통신 스폰서 서비스에 대한 서비스 개시 절차가 도 11에 도시되어 있다. 도 11은 본 발명의 실시예에 따른 통신 스폰서 서비스의 승인 절차를 도시하는 순서도이다.
통신 스폰서 서비스가 어플리케이션 스폰서 서비스와 다른 점은 무선단말가입자가 인터넷서비스 제공사업자의 서버로부터 서비스를 받는 것이 아니고, 이동통신 네트워크 사업자의 음성/비디오 전화와 같은 통신 서비스를 인터넷서비스제공사업자가 비용 부담을 하는 조건으로 무선단말가입자간에 수행할 수 있다는 점이다.
이는 기업에서 기업 가입자간의 통화를 이동통신 네트워크의 IMS 기반으로 하되, 비용은 기업이 부담하는 것과 같은 구조이다. 인터넷서비스 제공사업자의 경우도 자사의 서비스에서 사용자간 통신 서비스가 필요한 경우에 대해서 (예를 들면, 무선단말사용자와 자사의 담당자간 통신 등), 해당 통신 서비스를 인터넷서비스제공사업자가 직접 개발하여 운용하지 않더라도 이동통신 네트워크 사업자의 인프라를 빌려쓰는 것이라고 볼 수 있다.
구체적으로 살펴보면, 무선단말의 스폰서 서비스를 지원하는 어플리케이션(210)은 SSC 클라이언트(220)로부터 API를 호출하고 API는 스폰서 서비스 개시를 SSC 클라이언트(220)에게 요청한다. SSC 클라이언트(220)는 스폰서 서비스 개시 요청이 있는 경우, 1103단계에서 IMS 메시지인 스폰서 서비스 개시 요청 메시지 CSCF로 전송하게 된다. 도면에서 스폰서 서비스 개시 요청 메시지는 Invite 메시지로 표시된다.
IMS Invite 메세지의 수신지 주소는 상대방 가입자이고, via 필드는 마찬가지로 SSC 서버(230)가 된다. 이 경우, 해당 통신 서비스를 인터넷서비스 제공사업자가 지원한다는 것을 알리는 의미에서 ISP ID, Service ID를 데이타 필드에 포함한다. Service ID의 경우는 통신서비스에 대해서도 부여될 수 있으며, 이 경우 인터넷서비스제공사업자가 요청하는 통신서비스의 QoS 품질 등을 차별화하기 위한 용도로 설정할 수 있다. 이후, 1106단계에서 CSCF(260)는 Invite 메시지를 SSC 서버(230)로 전송한다.
SSC 서버(230)는 Invite 메시지 수신 후, 1109단계로 진행하여, AAA 서버(250)로 스폰서 서비스 정보를 포함하는 ISP 및 무선 단말 정보를 문의하여 획득한다.
상대방 단말기도 IMS 통신이 가능한 경우, SSC 서버(230)는 1112단계에서 Invite 메시지의 데이타 필드에 있는 ISP ID를 통해서 유효한 스폰서 서비스인지 여부를 판단하고 이후 게이트웨이의 QoS 파라메타 설정 정보가 있는지를 Service ID를 통해서 확인한다. 유효한 스폰서 서비스 사용 요청인 경우, SSC 서버(230)는 1115단계로 진행하여 Invite 메시지를 CSCF(260)로 전송하고, CSCF(260)는 1118단계에서 Invite 메시지를 ISP 서버(270)로 전송한다. 이미 무선단말이 전송한 메시지에 ISP ID가 있으므로, 이를 via 필드에 적용하여 전송한다.
1121단계에서 인터넷서비스 제공사업자가 유효한 스폰서에 대한 스폰서 서비스 사용 요청인지 여부를 판단한다. 인터넷서비스 제공사업자가 유효하다고 판단하는 경우, 1124 단계로 진행하여 ISP 서버(270)는 Invite 메시지를 CSCF(260)으로 전송한다. CSCF(260)는 1127단계에서 수신한 Invite 메시지를 상대방 무선단말(225)로 전송한다.
상대방 무선단말(225)은 Invite 메시지 확인 후, 1130단계에서 개시 승인 메시지를 CSCF(260)로 전송한다. 도면에서 개시 승인 메시지는 200 OK 메시지로 표시된다. CSCF(260)는 1133단계에서 수신한 200 OK 메시지를 ISP 서버(270)로 전송하고, ISP 서버(270)는 이를 확인 후 1136단계에서 다시 CSCF(260)로 전송하며, CSCF(260)는 1139단계에서 수신한 200 OK 메시지를 SSC 서버(230)로 전송한다.
SSC 서버(230)는 1142단계에서 200 OK메시지를 확인하여 스폰서 서비스가 유효함을 확인하고 1145단계로 진행하여 CSCF(260)로 개시 승인 메시지를 전송하고 1148단계에서 QoS정보와 Policy를 PGW/PCRF로 전송한다. 그 후 CSCF(260)는 1154단계에서 개시 승인 메시지를 SSC 클라이언트(220)로 전송한다.
SSC 클라이언트(220)는 1154단계에서 수신 확인 메시지를 CSCF(260)으로 전송한다. 도면에서 수신 확인 메시지는 ACK 메시지로 표시된다. 1160단계에서 CSCF(260)는 ACK 메시지를 SSC 서버(230)으로 전송하고, 1163단계에서 SSC 서버(230)는 ACK 메시지 메시지를 CSCF(260)으로 전송하며 1166단계에서 CSCF(260)는 ACK 메시지 메시지를 ISP 서버(270)로 전송한다. ISP 서버(270)는 1169단계에서 ACK 메시지 메시지를 CSCF(260)으로 전송하며 1172단계에서 CSCF(260)는 ACK 메시지 메시지를 상대방 단말(225)로 전송한다.
SSC 클라이언트(220)는 1157단계에서 ACK 메시지 메시지를 CSCF(260)으로 전송 후 스폰서 서비스 연결 성공에 대한 사항을 자체적인 Graphic User Interface (GUI)로써 알려준다. 이는 어플리케이션과 독립적으로 이루어지며, 사용자가 안심하고 스폰서 서비스를 사용할 수 있도록 하는 체제이다.
상대방 단말(225)이 ACK 메시지 확인 후, 1175단계에서 어플리케이션(210)과 상기 ISP 서버(270) 간 스폰서 서비스 세션이 생성된다.
통신 스폰서 서비스의 연결 해제 절차는 도 6에 도시된 실시예과 유사하므로 별도로 설명하지 않는다.
통신 스폰서 서비스도 앞서 어플리케이션 스폰서 서비스와 마찬가지로 인터넷서비스제공사업자가 IMS를 모르도록 하여 구현하는 것이 가능하다. 도 11에 도시되는 실시예의 단순화된 구조로서, SSC 서버(230)가 최종 결정을 내리도록 하는 절차가 도 12에 도시되어 있다. 연결설정과정에서 인터넷서비스제공사업자가 사라진 것을 제외하면 앞서 도 11에 도시된 실시예와 동일한 기능을 각 노드들이 수행한다.
도 12는 본 발명의 실시예에 따른 통신 스폰서 서비스의 간략화된 승인 절차를 도시하는 순서도이다.
구체적으로 살펴보면, 1205 -1225 단계는 1103 - 1115 단계와 동일하다. CSCF(260)는 1230단계에서 Invite 메시지를 상대방 무선단말(225)로 전송한다. 상대방 무선단말(225)은 Invite 메시지 확인 후, 1235단계에서 개시 승인 메시지를 CSCF(260)로 전송한다. 도면에서 개시 승인 메시지는 200 OK 메시지로 표시된다. CSCF(260)는 1240단계에서 수신한 200 OK 메시지를 SSC 서버(230)로 전송한다.
SSC 서버(230)는 1245단계에서 200 OK메시지를 확인하여 스폰서 서비스가 유효함을 확인하고 1250단계로 진행하여 CSCF(260)로 개시 승인 메시지를 전송하고, 1255단계에서 QoS정보와 Policy를 PGW/PCRF로 전송한다. 그 후, CSCF(260)는 1260단계에서 개시 승인 메시지를 SSC 클라이언트(220)로 전송한다.
SSC 클라이언트(220)는 1265단계에서 수신 확인 메시지를 CSCF(260)으로 전송한다. 도면에서 수신 확인 메시지는 ACK 메시지로 표시된다. 1275단계에서 CSCF(260)는 ACK 메시지를 SSC 서버(230)으로 전송하고, 1280단계에서 SSC 서버(230)는 ACK 메시지 메시지를 CSCF(260)으로 전송하며, 1285단계에서 CSCF(260)는 ACK 메시지 메시지를 상대방 단말(225)로 전송한다.
SSC 클라이언트(220)는 1270단계에서 ACK 메시지 메시지를 CSCF(260)으로 전송 후 스폰서 서비스 연결 성공에 대한 사항을 자체적인 Graphic User Interface (GUI)로써 알려준다. 이는 어플리케이션과 독립적으로 이루어지며, 사용자가 안심하고 스폰서 서비스를 사용할 수 있도록 하는 체제이다.
상대방 단말(225)이 ACK 메시지 확인 후, 1270단계에서 어플리케이션(210)과 상기 ISP 서버(270) 간 스폰서 서비스 세션이 생성된다.
마지막으로, 지능형 처리 및 컨텐츠 전송 스폰서 서비스 절차에 대해 설명한다.
도 13은 본 발명의 실시예에 따른 컨텐츠 전달 스폰서 서비스 절차를 도시하는 순서도이다.
일반적인 무선단말가입자로부터 인터넷서비스 제공사업자로의 컨텐츠 전송 요청의 경우 도 13의 1310, 1330 및 1340단계로 이루어진다. 즉, 1310단계에서 무선단말에서 Hyper Text Transport Protocol (HTTP) 등의 전송 프로토콜을 통해서 응용서비스서버에 접속하면, 1330단계에서 해당 응용서비스서버는 응답을 주면서 추가적인 컨텐츠의 전송이 필요한 경우, 해당 응답에 해당 컨텐츠가 저장된 저장서버의 이름과 위치를 알려준다.
그 후, 1340단계에서 무선단말은 다시 해당 컨텐츠가 저장된 저장서버로 가서 위치의 컨텐츠 파일을 읽어들인다. 이때, 무선단말이 HTTP 등의 전송 전에 도 5와 같은 절차를 수행함으로써, 해당 저장서버와의 컨텐츠 송수신은 스폰서 서비스로서 지원되게 된다. 이에 추가적으로 지능적인 서비스를 더 하게 되는 것이 본 발명에 따른 지능형 처리 및 컨텐츠 전송 스폰서 서비스이다.
즉 1320단계에서 컨텐츠 요청 매트릭스를 업데이트 또는 확인하고, 1350단계에서 스폰서 응용서비스 서버 IP 주소 교체 리포트 전송 시 1360단계에서 스폰서 응용서비스 IP 주소 교체 응답을 전송하는 과정이 추가되는 것이다. 그 후, 1370단계에서 스폰서 컨텐츠 전송이 이루어진다.
본 발명의 실시예에 따른 지능형 처리 및 컨텐츠 전송 스폰서 서비스의 개념을 도 14에서 도시하고 있다. 도 14의 1)에서처럼 무선단말은 인터넷서비스 제공사업자의 서비스서버에 접속할 때 SSC 서버(230)의 정보를 함께 전송한다. 이는 도 13의 1번 시퀀스에 내재한 것으로, 본 발명에서는 무선단말이 접속한 지점을 담당하는 SSC 서버(230)를 인터넷서비스 서버에게 알리는 용도이다. 인터넷서비스 서버는 도 13과 같이 자신의 프로세서와 저장장치를 통하여 서비스를 제공하다가, 특정 지역에서의 컨텐츠 요청이 일정 수위를 넘어가서 과다하게 발생하는 경우, 도 14의 2)처럼 해당 지역을 담당하는 SSC 서버(230)에게 인터넷서비스 서버의 컨텐츠를 대신 전송해 달라고 요청한다. 즉, 인터넷서비스 서버에서 과다한 트래픽이 이동통신 네트워크로 전송되어 다시 무선을 통해 무선단말들에게 전송되지 않고, 무선에 가장 가까운 SSC 서버(230)에서 바로 인터넷서비스 서버의 컨텐츠를 전송하도록 하는 것이다.
SSC 서버(230)와 인터넷서비스 서버와의 협의가 마쳐지면, 실제 컨텐츠가 이동통신 네트워크의 SSC 서버(230)가 관장하는 컨텐츠 저장 서버로 이동하는 과정이 3)에 나타나 있다. 이후, 해당 컨텐츠에 대한 요청이 SSC 서버(230)의 관할 지역에서 올라오면, 해당 컨텐츠는 SSC 서버(230) 인터넷서비스 제공사업자의 인터넷서비스 서버를 대신하여 SSC 서버(230) 휘하의 서버들에 의하여 전송된다. 따라서, 인터넷서비스 서버에서 이동통신 네트워크로 트래픽이 전송되면서 발생했던 지연 시간은 줄어들게 된다. 더불어, 무선에 가까운 이동통신 네트워크 내부에서 바로 무선단말로 응답을 전송하게 되므로, 서비스의 품질은 향상된다.
도 14의 2)와 3)에 해당 하는 내용이 도 15에 보다 구체적으로 설명되어 있다.
HTTP 프로토콜 등을 구동하는 인터넷서비스 제공사업자의 ISP 서버 (Controller)(271)는 특정 지역으로부터 특정 컨텐츠에 대한 요청이 과다하게 발생하면, 이를 일정 시간 단위로 모니터링하고 있다가, 1510단계에서 해당 지역의 SSC 서버(Controller)(231)에게 컨텐츠 대행 전송을 요청하는 메시지를 전송하게 된다. 이때 본인의 ISP ID와 대행하여 전송을 요청하는 컨텐츠의 특징을 적은 정보를 SSC 서버(Controller)(231)에 전달한다. SSC 서버(Controller)(231)는 해당 정보를 기반으로 대행 전송이 가능한 컨텐츠로 판단되면, 1520단계에서 가능하다는 응답을 ISP 서버 (Controller)(271)에 다시 전송한다. 이를 수신한 ISP 서버(Controller)(271)는 1530단계에서 자신의 Storage 서버(272)에게 SSC 서버(Controller)(230) 휘하의 Storage 서버(232)로 해당 컨텐츠를 전송하도록 요청한다. 1540단계에서 컨텐츠 전송이 이루어지게 된다. SSC 서버(Controller)(231)는 1550단계에서 컨텐츠를 확인하고, 1560단계에서 전송받은 컨텐츠를 SSC 서버(storage)(232)에 저장하게 된다. 이후, Storage 서버들 간의 컨텐츠 전송이 종료되면, SSC 서버(230)는 1570단계에서 해당 컨텐츠에 대한 접근 URI를 생성하여 ISP 서버 (Controller)(271)에게 이를 포함하는 확인 메시지를 전달한다.
이와 같은 과정은 컨텐츠의 위치가 인터넷서비스 서버가 아닌 이동통신 네트워크 내부의 SSC 서버(230) 휘하의 저장서버(232)이므로, 해당 저장서버(232)에서의 해당 파일의 신규 위치를 URI로 만들어 ISP 서버 (Controller)(271)에게 전달하는 것이다.
이때 SSC 서버(230)는 추가적으로, 자신의 저장서버(232)를 컨텐츠 저장위치로 사용하는 서비스들의 품질을 보장하고, 아울러 스폰서 서비스로 대신 과금할 비용을 청구하기 위한 통계정보 확보를 위하여, 1580단계에서 해당 컨텐츠에 대한 정보를 게이트웨이에게 넘겨 PGW(280)/PCRF(290) 등의 게이트웨이가 해당 이동된 컨텐츠의 전송에 차별화된 품질을 제공하고, 통계정보를 모으도록 한다.
아울러, 도 15의 1번 시퀀스에서 해당 컨텐츠의 전송에 추가적인 QoS 보장을 요청받았다면, 1580단계에서 이에 대한 설정도 해당 PGW(280)/PCRF(290) 로 전송하다.
도 16은 본 발명의 실시예에 따른 이동통신 네트워크 내의 컨텐츠를 활용한 인터넷 서비스 절차를 도시하는 순서도이다.
도 16에 도시하는 바와 같이, 1610단계에서 이전된 컨텐츠에 대해서 무선단말(210)이 ISP 서버(Controller)(271)로 전송 요청을 하는 경우, ISP 서버 (Controller)(271)는 1620단계에서 컨텐츠 요청 매트릭스를 업데이트 또는 확인 후, 1630단계에서 컨텐츠의 위치를 SSC 서버(230) 휘하의 저장서버 URI가 포함된 응답을 전달하게 된다. 이로써, 무선단말(210)은 1640단계에서 컨텐츠의 액세스 시 해당 SSC 서버(230)의 저장서버(232)에서 빠르게 컨텐츠를 액세스하고 1650단계에서 컨텐츠를 전송받게 된다. 액세스가 발생한 컨텐츠에 대해서는 SSC 서버(230) 휘하의 저장서버(232)가 1660단계에서 건별로 과금 정보를 생성하여 AAA 서버로 전달하게 되며, 이를 통하여 이후 인터넷서비스제공사업자에 대한 과금을 수행한다.
ISP 서버(Controller)(271)는 무선단말(210)로부터의 컨텐츠 전송 요청에 대한 관문으로서 얼마만큼 해당 컨텐츠에 대한 요청이 오는 지를 판단할 수 있다. 따라서, 일정 시간 동안 SSC 서버(230) 휘하의 저장서버로 전달한 컨텐츠에 대해서 요청이 줄어들게 되면, 인터넷서비스제공사업자는 해당 이동통신 네트워크 내부로 이동한 컨텐츠를 제거하고, 다시 직접 무선단말로의 컨텐츠 전송에 나설 수 있다.
도 17은 본 발명의 실시예에 따른 이동통신 네트워크 내의 컨텐츠 제거 절차를 도시하는 순서도이다.
SSC 서버(Controller)(271)는 1710단계에서 SSC 서버(controller)(231)에게 본인을 알리는 ISP ID와 앞서 컨텐츠 이전 시 SSC 서버(controller)(231)가 알려준 컨텐츠의 URI 를 전달하여, 해당 컨텐츠의 대행 전송을 중지하도록 요청한다. 이를 수신한 SSC 서버(controller)(231)는 1720단계에서 컨텐츠를 확인 후, 1730단계에서 해당 컨텐츠를 휘하의 저장서버(232)에서 제거하고, 1740단계에서 컨텐츠 제거 응답을 ISP 서버(controller)(271)로 전송한다. 그 후, 1750단계에서 지금까지 최종적으로 대행 전송한 컨텐츠의 정보를 과금서버로 전달한다.
도 17에 도시된 과정을 통하여 일종의 Content Delivery Network (CDN)의 효과를 제공할 수 있다.
추가적으로 인터넷서비스 제공사업자가 ISP 서버(Controller)(271)와 같은 서비스 컨트롤러의 기능도 임시적으로 이동통신 사업자의 것을 쓰고자 한다면, ISP 서버(Controller)(271)에서는 무선단말로부터 요청된 HTTP Request 등의 메시지를 받기만 하고, 바로 이동통신 네트워크에 임시로 빌린 프로세서상의 SSC 서버(230) 휘하의 서버(Controller)로 재전송하기만 하면 된다.
상기와 같은 절차가 도 18 내지 도 21에 도시된다. 이와 같은 과정은 도 15내지 도17에 대응된다.
도 18은 본 발명의 실시예에 따른 처리 및 컨텐츠 스폰서 서비스 절차를 도시하는 순서도이다.
1810단계에서 이전된 컨텐츠에 대해서 무선단말(210)이 ISP 서버(Controller)(271)로 전송 요청을 하는 경우, ISP 서버 (Controller)(271)는 1820단계에서 컨텐츠 요청 매트릭스를 업데이트 또는 확인 후, 1830단계에서 컨텐츠가 위치한 ISP 서버(270)의 ID가 포함된 응답을 전달하게 된다. 무선단말(210)은 1840단계에서 변경된 ISP 서버(270)로 네트워크 서비스 요청을 하고, 필요한 경우, 1850단계에서 스폰서 ISP 서버(270‘) IP 주소 교체 리포트를 PGW(280)/PCRF(290)에 전송한다. 그 후, 1860단계에서 PGW(280)/PCRF(290)는 스폰서 ISP 서버(270‘) IP 주소 교체 응답을 무선단말(210)로 전송한다. 그 후, 무선단말(210)과 스폰서 ISP 서버(270‘) 간에 처리/저장 세션이 생성된다.
도 19는 이동통신 네트워크로의 처리부/컨텐츠 이동 절차를 도시하는 순서도이다.
HTTP 프로토콜 등을 구동하는 인터넷서비스 제공사업자의 ISP 서버 (Controller)(271)는 특정 지역으로부터 특정 컨텐츠에 대한 요청이 과다하게 발생하면, 이를 일정 시간 단위로 모니터링하고 있다가, 1910단계에서 해당 지역의 SSC 서버(Controller)(231)에게 컨텐츠 대행 전송을 요청하는 메시지를 전송하게 된다. SSC 서버(Controller)(231)는 해당 정보를 기반으로 대행 전송이 가능한 컨텐츠로 판단되면, 1920단계에서 가능하다는 응답을 ISP 서버 (Controller)(271)에 다시 전송한다. 이를 수신한 ISP 서버(Controller)(271)는 1930단계에서 ISP 서버(270)에 저장된 어플리케이션과 컨텐츠를 전송하도록 요청한다. 그 후, 1940단계에서 컨텐츠 전송이 이루어지게 된다. SSC 서버(Controller)(231)는 1950단계에서 컨텐츠를 확인하고, 1960단계에서 전송받은 어플리케이션과 컨텐츠를 SSC 서버(230)에 저장하게 된다. 이후, 컨텐츠 전송이 종료되면, SSC 서버(controller)(231)는 1970단계에서 해당 컨텐츠에 대한 접근 URI를 생성하여 ISP 서버(Controller)(271)에게 이를 포함하는 확인 메시지를 전달한다.
이때 SSC 서버(230)는 추가적으로, 자신의 저장서버(232)를 컨텐츠 저장위치로 사용하는 서비스들의 품질을 보장하고, 아울러 스폰서 서비스로 대신 과금할 비용을 청구하기 위한 통계정보 확보를 위하여, 1980단계에서 해당 컨텐츠에 대한 정보를 게이트웨이에게 넘겨 PGW(280)/PCRF(290) 등의 게이트웨이가 해당 이동된 컨텐츠의 전송에 차별화된 품질을 제공하고, 통계정보를 모으도록 한다.
아울러, 도 15의 1번 시퀀스에서 해당 컨텐츠의 전송에 추가적인 QoS 보장을 요청받았다면, 1580단계에서 이에 대한 설정도 해당 PGW(280)/PCRF(290) 로 전송하다.
도 20은 이동통신 네트워크 내의 처리부/컨텐츠를 활용한 인터넷 서비스 절차를 도시하는 순서도이다.
2010단계에서 이전된 컨텐츠에 대해서 무선단말(210)이 ISP 서버(Controller)(271)로 전송 요청을 하는 경우, ISP 서버 (Controller)(271)는 2020단계에서 컨텐츠 요청 매트릭스를 업데이트 또는 확인 후, 2030단계에서 컨텐츠의 위치를 SSC 서버(230) 휘하의 저장서버 URI가 포함된 응답을 전달하게 된다. 이로써, 무선단말(210)은 2040단계에서 컨텐츠의 액세스 시 해당 SSC 서버(230)에게 너트워크 서비스를 요청하게 되고, 2050단계에서 스폰서된 처리 및 컨텐츠 세션을 생성하게 된다. 그 후, SSC 서버(230)는 2060단계에서 건별로 과금 정보를 생성하여 AAA 서버(250)로 전달하게 되며, 이를 통하여 이후 인터넷서비스제공사업자에 대한 과금을 수행한다.
도 21은 이동통신 네트워크 내의 처리부/컨텐츠 제거 절차를 도시하는 순서도이다.
ISP 서버(Controller)(271)는 2110단계에서 SSC 서버(controller)(231)에게 본인을 알리는 ISP ID와 앞서 어플리케이션 및 컨텐츠 이전 시 SSC 서버(controller)(231)가 알려준 어플리케이션과 컨텐츠의 URI 를 전달하여, 해당 어플리케이션과 컨텐츠의 대행 전송을 중지하도록 요청한다. 이를 수신한 SSC 서버(controller)(231)는 2120단계에서 컨텐츠를 확인 후, 2130단계에서 해당 어플리케이션 및 컨텐츠를 휘하의 저장서버(232)에서 제거하고, 2140단계에서 컨텐츠 제거 응답을 ISP 서버(controller)(271)로 전송한다. 그 후, 2150단계에서 지금까지 최종적으로 대행 전송한 컨텐츠의 정보를 과금서버로 전달한다.
도 22는 SSC 서버의 어플리케이션 스폰서 서비스 승인 절차를 도시하는 순서도이다.
SSC 서버(230)는 2205단계에서 수신한 Invite 메시지로부터 스폰서쉽 ID, IDP ID 및 서비스 ID를 추출하고 2210단계에서 ISP ID 및 서비스 ID에 대응하는 스폰서 서비스 정보를 추출한다.
그 후, SSC 서버(230)는 2215단계에서 유효한 ISP ID 또는 서비스 ID 인지 여부를 판단한다. SSC 서버(230)가 유효한 ISP ID 또는 서비스 ID로 판단하는 경우, SSC 서버(230)는 2220단계로 진행하여 날짜/시간 옵션이 존재하는지 여부를 판단한다. SSC 서버(230)가 날짜/시간 옵션이 존재하지 않는다고 판단하는 경우, SSC 서버(230)는 2230단계로 진행하여 지역옵션이 존재하는지 여부를 판단한다. SSC 서버(230)가 지역 옵션이 존재하지 않는다고 판단하는 경우, SSC 서버(230)는 2240단계로 진행하여 ID 옵션이 존재하는지 여부를 판단한다. SSC 서버(230)가 ID 옵션이 존재하지 않는다고 판단하는 경우, 2260단계로 진행하여 요청을 승인하고 OK 결과와 함께 ISP 서버(270)에 Invite 메시지를 전송한다.
2215단계에서 SSC 서버(230)가 유효하지 않은 ISP ID 또는 서비스 ID로 판단하는 경우, 2250단계로 진행하여 데이터베이스에 비정상 사용에 대해 기록한다. 그후 2270단계로 진행하여 요청을 무시하고 NOK 결과와 함께 488 거절 메시지를 사용자 단말에 전송한다.
2220단계에서 SSC 서버(230)가 날짜/시간 옵션이 존재한다고 판단하는 경우, SSC 서버(230)는 2225단계로 진행하여 유효한 날짜/시간인지 여부를 판단하고, SSC 서버(230)가 유효한 날짜/시간으로 판단하는 경우 2230단계로 진행한다. SSC 서버(230)가 유효하지 않은 날짜/시간으로 판단하는 경우 2250단계로 진행한다.
2230단계에서 SSC 서버(230)가 지역 옵션이 존재한다고 판단하는 경우, SSC 서버(230)는 2235단계로 진행하여 유효한 지역인지 여부를 판단하고, SSC 서버(230)가 유효한 지역으로 판단하는 경우 2230단계로 진행한다. SSC 서버(230)가 유효하지 않은 지역으로 판단하는 경우 2250단계로 진행한다.
2230단계에서 SSC 서버(230)가 ID 옵션이 존재한다고 판단하는 경우, SSC 서버(230)는 2245단계로 진행하여 유효한 ID인지 여부를 판단하고, SSC 서버(230)가 유효한 ID로 판단하는 경우 2260단계로 진행한다. SSC 서버(230)가 유효하지 않은 지역으로 판단하는 경우 2250단계로 진행한다.
도 23은 SSC 서버의 어플리케이션 스폰서 서비스의 QoS/통계정보 설정 절차를 도시하는 순서도이다.
SSC 서버(230)는 2310단계에서 200 OK 메시지로부터 결과를 추출한다. 그 후 2320단계에서 결과가 OK인지 여부를 판단한다. 결과를 추출한 경우, SSC 서버(230)는 2330단계로 진행하여 QoS 정보가 존재하는지 여부를 판단한다. QoS 정보가 존재하는 경우, SSC 서버(230)는 2350단계로 진행하여 OK 메시지로부터 QoS 정보를 추출한다. 그 후 SSC 서버(230)는 2360단계로 진행하여 서비스 ID를 위한 QoS 정보를 업데이트한다.
다음으로 SSC 서버(230)는 2370단계에서 QoS 및 Policy 강제 메시지를 생성하고 2380단계에서 QoS 및 Policy 강제 메시지를 게이트웨이로 전송한다. 그 후, 2390단계에서 사용자 단말로 200 OK 메시지를 전달한다.
SSC 서버(230)가 2320단계에서 결과를 추출하지 않은 경우, 2390단계로 진행한다.
SSC 서버(230)가 2330단계에서 QoS 정보가 존재하지 않는다고 판단하는 경우, SSC 서버(230)는 2340단계로 진행하여 데이터베이스 메시지로부터 서비스 ID를 위한 QoS 정보를 추출하고 2370단계로 진행한다.
도 24는 SSC 서버의 과금 정보 생성 및 전달 절차를 도시하는 순서도이다.
SSC 서버(230)는 2410단계에서 PGW로부터 CDR 정보를 추출한다. 그 후 2420단계에서 CDR에 SSC 서버(230) 계정 정보를 추가하고 2430단계로 진행하여 AAA 서버로 CDR을 전송한다. 다음으로 SSC 서버(230)는 2440단계로 진행하여 통화 과금 요약 정보를 생성하고, 2450단계로 진행하여 Bye 메시지에 통화 과금 요약 정보를 추가하며, 2460단계로 진행하여 ISP 서버에 Bye 메시지를 전달한다.
SSC 서버(230)는 2470단계에서 ISP 서버로부터 200 OK 메시지 수신여부를 판단한다. SSC 서버(230)가 200 OK 메시지를 수신하였다고 판단하는 경우, SSC 서버(230)는 2480단계로 진행하여 200 OK 메시지에 통화 과금 요약 정보를 추가하고 2490단계에서 사용자 단말로 200 OK 메시지를 전달한다.
SSC 서버(230)가 2470단계에서 200 OK 메시지를 수신하지 않았다고 판단하는 경우, 다시 2470단계를 수행한다.
도 25는 SSC 서버의 통신 스폰서 서비스 승인 절차를 도시하는 순서도이다.
SSC 서버(230)는 2505단계에서 수신한 Invite 메시지로부터 스폰서쉽 ID, IDP ID 및 서비스 ID를 추출하고 2210단계에서 ISP ID 및 서비스 ID를 추출한다.
그 후, SSC 서버(230)는 2510단계에서 유효한 상대방 단말인지 여부를 판단한다. SSC 서버(230)가 유효한 상대방 단말이라고 판단하는 경우, 2515단계로 진행하여 상대방 단말이 IMS ID 인지 여부를 판단한다. SSC 서버(230)가 상대방 단말이 IMS ID라고 판단하는 경우, 2520단계에서 ISP ID 및 서비스 ID에 대응하는 스폰서 서비스 정보를 추출한다.
그 후, SSC 서버(230)는 2525단계에서 유효한 ISP ID 또는 서비스 ID 인지 여부를 판단한다. SSC 서버(230)가 유효한 ISP ID 또는 서비스 ID로 판단하는 경우, SSC 서버(230)는 2530단계로 진행하여 날짜/시간 옵션이 존재하는지 여부를 판단한다. SSC 서버(230)가 날짜/시간 옵션이 존재하지 않는다고 판단하는 경우, SSC 서버(230)는 2540단계로 진행하여 지역옵션이 존재하는지 여부를 판단한다. SSC 서버(230)가 지역 옵션이 존재하지 않는다고 판단하는 경우, SSC 서버(230)는 2550단계로 진행하여 ID 옵션이 존재하는지 여부를 판단한다. SSC 서버(230)가 ID 옵션이 존재하지 않는다고 판단하는 경우, 2565단계로 진행하여 요청을 승인하고 OK 결과와 함께 ISP 서버(270)에 Invite 메시지를 전송한다.
2525단계에서 SSC 서버(230)가 유효하지 않은 ISP ID 또는 서비스 ID로 판단하는 경우, 2560단계로 진행하여 데이터베이스에 비정상 사용에 대해 기록한다. 그 후 2570단계로 진행하여 요청을 무시하고 NOK 결과와 함께 488 거절 메시지를 사용자 단말에 전송한다.
2530단계에서 SSC 서버(230)가 날짜/시간 옵션이 존재한다고 판단하는 경우, SSC 서버(230)는 2535단계로 진행하여 유효한 날짜/시간인지 여부를 판단하고, SSC 서버(230)가 유효한 날짜/시간으로 판단하는 경우 2540단계로 진행한다. SSC 서버(230)가 유효하지 않은 날짜/시간으로 판단하는 경우 2560단계로 진행한다.
2540단계에서 SSC 서버(230)가 지역 옵션이 존재한다고 판단하는 경우, SSC 서버(230)는 2545단계로 진행하여 유효한 지역인지 여부를 판단하고, SSC 서버(230)가 유효한 지역으로 판단하는 경우 2550단계로 진행한다. SSC 서버(230)가 유효하지 않은 지역으로 판단하는 경우 2560단계로 진행한다.
2550단계에서 SSC 서버(230)가 ID 옵션이 존재한다고 판단하는 경우, SSC 서버(230)는 2555단계로 진행하여 유효한 ID인지 여부를 판단하고, SSC 서버(230)가 유효한 ID로 판단하는 경우 2265단계로 진행한다. SSC 서버(230)가 유효하지 않은 지역으로 판단하는 경우 2560단계로 진행한다.
도 26은 ISP 서버의 지능형 처리 및 컨텐츠 전송 스폰서 서비스 절차를 도시하는 순서도이다.
ISP 서버(controller)(271)는 2605단계에서 HTTP 요청 메시지로부터 SSC 서버 ID를 추출한다. 그 후, ISP 서버(controller)(271)는 2610단계에서 새로운 SSC 서버 ID인지 여부를 판단한다. ISP 서버(controller)(271)가 새로운 SSC 서버 ID가 아니라고 판단하는 경우, 2615단계로 진행하여 데이터베이스로부터 처리 정보를 추출한다. 그 후, ISP 서버(controller)(271)는 2625단계에서 빈도가 임계점에 도달하는지 여부를 판단한다. ISP 서버(controller)(271)가 빈도가 임계점에 도달한다고 판단하는 경우, 2630단계로 진행하여 컨텐츠를 전송하기 위하여 SSC 서버에 접속한다.
다음으로, ISP 서버(controller)(271)는 2635단계에서 전송 허가 여부를 판단한다. ISP 서버(controller)(271)가 전송이 허가되었다고 판단하는 경우, 2640단계로 진행하여 SSC 서버(230)에 컨텐츠를 전송한다.
그 후, ISP 서버(controller)(271)는 2645단계에서 새로운 URI 수신 여부를 판단한다. ISP 서버(controller)(271)가 새로운 URI 수신하였다고 판단하는 경우, 2650단계로 진행하여 데이터베이스에 URI를 추가하고 2655단계로 진행하여 새로운 URI를 사용하여 컨텐츠를 위한 새로운 HTML 페이지를 생성한다.
ISP 서버(controller)(271)가 2610단계에서 새로운 SSC 서버 ID라고 판단하는 경우, 2620단계로 진행하여 CDR에 SSC 서버 계정 정보를 추가 후 종료한다.
ISP 서버(controller)(271)가 2625단계에서 빈도가 임계점에 도달하지 않았다고 판단하는 경우, 바로 종료한다.
ISP 서버(controller)(271)가 2635단계에서 전송이 허가되지 않았다고 판단하는 경우, 바로 종료한다.
ISP 서버(controller)(271)가 2645단계에서 새로운 URI가 수신되지 않았다고 판단하는 경우, 바로 종료한다.
본 명세서와 도면에 개시된 본 발명의 실시예들은 본 발명의 기술 내용을 쉽게 설명하고 본 발명의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시예들 이외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.

Claims (9)

  1. IMS 기반의 이동통신 네트워크에서 인터넷 서비스 제공 서버(Internet Service Provider Server)가 단말의 이동통신 사용 요금을 대납할 수 있는 스폰서 서비스(Sponsored Service) 제공하는 방법에 있어서,
    상기 스폰서 서비스를 제공하기 위하여 상기 단말에 포함된 스폰서 서비스 클라이언트(Sponsored Service and Connectivity Client)가 상기 스폰서 서비스를 제공하기 위한 스폰서 서비스 서버(Sponsored Service Sever)에 상기 스폰서 서비스 개시 요청 메시지를 전송하는 단계;
    상기 스폰서 서비스 서버가 상기 개시 요청 메시지 수신 후, 상기 스폰서 서비스의 유효 여부를 판단하는 단계;
    상기 스폰서 서비스 서버가 상기 스폰서 서비스가 유효하다고 판단하는 경우, 스폰서 서비스 개시 승인 메시지를 상기 스폰서 서비스 클라이언트로 전송하는 단계;
    상기 스폰서 서비스 클라이언트와 상기 인터넷 서비스 제공 서버 간 스폰서 서비스 세션을 생성하는 단계;
    상기 스폰서 서비스 클라이언트의 상기 스폰서 서비스 종료 요청 시, 상기 스폰서 서비스 서버가 과금 정보를 생성하고 AAA 서버(Authentication/Authorization/ Accounting Sever)로 상기 과금정보를 전송하는 단계; 및
    상기 스폰서 서비스 세션을 종료하는 단계를 포함하는 것을 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 방법.
  2. 제1항에 있어서,
    상기 스폰서 서비스 서버가 스폰서 서비스 개시 승인 메시지를 상기 단말로 전송하는 단계는,
    상기 스폰서 서버가 상기 인터넷 서비스 제공 서버로 상기 스폰서 서비스 개시 요청 메시지를 전송하는 단계;
    상기 인터넷 서비스 제공 서버가 상기 스폰서 서비스의 유효 여부를 판단하는 단계;
    상기 인터넷 서비스 제공 서버가 상기 스폰서 서비스가 유효하다고 판단하는 경우, 스폰서 서비스 서버로 상기 개시 승인 메시지를 전송하는 단계; 및
    상기 스폰서 서비스 서버가 상기 개시 승인 메시지를 상기 스폰서 서비스 클라이언트로 전송하는 단계를 포함하는 것을 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 방법.
  3. 제2항에 있어서,
    상기 인터넷 서비스 제공 서버가 상기 개시 승인 메시지를 전송하는 단계는,
    상기 인터넷 서비스 제공 서버가 상기 스폰서 서비스가 유효하다고 판단한 경우, 상대방 무선 단말로 상기 개시 요청 메시지를 전송하는 단계;
    상기 상대방 무선 단말이 상기 인터넷 서비스 제공 서버로 개시 승인 메시지를 전송하는 단계; 및
    상기 인터넷 서비스 제공 서버가 상기 개시 승인 메시지 수신 후, 상기 스폰서 서비스 서버로 상기 개시 승인 메시지를 전송하는 단계를 포함하고,
    상기 스폰서 서비스 세션은 상기 스폰서 서비스 클라이언트와 상기 상대방 무선 단말 간에 생성하는 것을 포함하는 것을 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 방법.
  4. 제2항에 있어서,
    상기 인터넷 서비스 제공 서버가 상기 개시 승인 메시지를 전송하는 단계는,
    상기 인터넷 서비스 제공 서버가 상기 개시 승인 메시지에 QoS 정보를 추가하여 상기 스폰서 서비스 서버로 개시 승인 메시지를 전송하는 것을 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 방법.
  5. 제4항에 있어서,
    상기 스폰서 서비스 서버가 상기 개시 승인 메시지를 상기 스폰서 서비스 클라이언트로 전송하는 단계는,
    상기 개시 승인 메시지로부터 QoS 정보를 추출하는 단계;
    상기 SSC 서버가 상기 QoS 정보를 업데이트하는 단계;
    상기 Qos 정보에 따라 QoS 및 Policy 강제 메시지를 생성하는 단계;
    QoS 및 Policy 강제 메시지를 게이트웨이로 전송하는 단계; 및
    상기 개시 승인 메시지를 상기 무선단말로 전송하는 단계를 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 방법.
  6. 제1항에 있어서,
    상기 과금 정보를 전송하는 단계는,
    게이트웨이로부터 CDR(Call Detail Recording) 정보를 추출하는 단계;
    상기 CDR 정보에 상기 SSC 서버 계정 정보를 추가하여 과금 정보를 생성하는 단계; 및
    상기 AAA 서버로 상기 과금 정보를 전송하는 단계를 포함하는 것을 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 방법.
  7. 제6항에 있어서,
    상기 스폰서 서비스 서버가 상기 과금 정보를 상기 스폰서 서비스 클라이언트로 전송하는 단계를 포함하는 것을 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 방법.
  8. 제1항에 있어서,
    상기 SSC 서버가 상기 스폰서 서비스 유효 여부 판단 시,
    ISP ID, 서비스 ID, 날짜, 시간, 지역 또는 IMS ID 중 어느 하나를 이용하여 스폰서 서비스 유효 여부를 판단하는 것을 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 방법.
  9. IMS 기반의 이동통신 네트워크에서 인터넷 서비스 제공 서버(Internet Service Provider Server)가 단말의 이동통신 사용 요금을 대납할 수 있는 스폰서 서비스(Sponsored Service) 제공 시스템으로,
    상기 스폰서 서비스를 제공하기 위하여 상기 단말에 포함된 스폰서 서비스 클라이언트(Sponsored Service and Connectivity Client), 상기 스폰서 서비스를 제공하기 위한 스폰서 서비스 서버(Sponsored Service Sever), 상기 인터넷 서비스 제공 서버 및 AAA 서버(Authentication/Authorization/ Accounting Sever)를 포함하고,
    상기 스폰서 서비스 클라이언트(Sponsored Service and Connectivity Client)가 상기 스폰서 서비스 서버(Sponsored Service Sever)에 상기 스폰서 서비스 개시 요청 메시지를 전송하는 단계;
    상기 스폰서 서비스 서버가 상기 개시 요청 메시지 수신 후, 상기 스폰서 서비스의 유효 여부를 판단하는 단계;
    상기 스폰서 서비스 서버가 상기 스폰서 서비스가 유효하다고 판단하는 경우, 스폰서 서비스 개시 승인 메시지를 상기 스폰서 서비스 클라이언트로 전송하는 단계;
    상기 스폰서 서비스 클라이언트와 상기 인터넷 서비스 제공 서버 간 스폰서 서비스 세션을 생성하는 단계;
    상기 스폰서 서비스 클라이언트의 상기 스폰서 서비스 종료 요청 시, 상기 스폰서 서비스 서버가 과금 정보를 생성하고 AAA 서버(Authentication/Authorization/ Accounting Sever)로 상기 과금정보를 전송하는 단계; 및
    상기 스폰서 서비스 세션을 종료하는 단계를 포함하는 것을 특징으로 하는 스폰서 서비스(Sponsored Service) 제공 시스템.
PCT/KR2012/010566 2011-12-06 2012-12-06 Ims 기반의 이동통신 네트워크에서 스폰서 서비스 제공 방법 및 시스템 WO2013085314A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/363,772 US10033878B2 (en) 2011-12-06 2012-12-06 Method and system for providing sponsored service on IMS-based mobile communication network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2011-0129931 2011-12-06
KR1020110129931A KR101844304B1 (ko) 2011-12-06 2011-12-06 Ｉｍｓ 기반의 이동통신 네트워크에서 스폰서 서비스 제공 방법 및 시스템

Publications (1)

Publication Number Publication Date
WO2013085314A1 true WO2013085314A1 (ko) 2013-06-13

Family

ID=48574600

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/010566 WO2013085314A1 (ko) 2011-12-06 2012-12-06 Ims 기반의 이동통신 네트워크에서 스폰서 서비스 제공 방법 및 시스템

Country Status (3)

Country Link
US (1) US10033878B2 (ko)
KR (1) KR101844304B1 (ko)
WO (1) WO2013085314A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3007484A1 (en) * 2014-10-10 2016-04-13 Samsung Electronics Co., Ltd. Method and apparatus for controlling traffic in a wireless communication system
CN105611517A (zh) * 2014-11-18 2016-05-25 三星电子株式会社 用于在移动通信系统的用户设备中提供服务的方法和装置
WO2016076628A3 (ko) * 2014-11-11 2016-07-14 삼성전자 주식회사 이동통신 네트워크를 통한 데이터 서비스 제공 방법 및 장치
WO2016175578A1 (ko) * 2015-04-28 2016-11-03 삼성전자 주식회사 무선 통신 시스템에서 데이터 서비스 제공 방법 및 장치

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9125106B1 (en) * 2013-09-11 2015-09-01 Sprint Spectrum L.P. Management of quality of service policy changes in a communication network based on whether the policy change is an upgrade or a downgrade
US9210687B1 (en) * 2013-09-25 2015-12-08 Sprint Spectrum L.P. Management of wireless service in a dual RAN arrangement
KR102309744B1 (ko) * 2014-11-21 2021-10-07 삼성전자 주식회사 세션 기반 웹 서비스를 제공하는 방법 및 장치
KR102220181B1 (ko) 2014-11-28 2021-02-25 삼성전자주식회사 단말간 스폰서링 서비스를 제공하기 위한 방법 및 장치
WO2016103052A1 (en) * 2014-12-23 2016-06-30 Orange Alternative toll-free architecture and simple deployment modules
US10986526B2 (en) 2015-05-26 2021-04-20 Lg Electronics Inc. Method and terminal for transmitting data traffic in wireless communication system
US10193942B2 (en) * 2015-10-26 2019-01-29 Verizon Patent And Licensing Inc. Mobile media architecture for sponsored data services

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006500879A (ja) * 2002-10-12 2006-01-05 エルジー エレクトロニクス インコーポレイティド 無線ｌａｎネットワークと移動通信ネットワークの連動構造における課金情報処理方法
KR100789868B1 (ko) * 2007-06-20 2007-12-28 (주)씨맥스와이어리스 ＩＭＳ망과 휴대 인터넷망(ＷｉＢｒｏ/ＷｉＭＡＸ)간의서비스 품질 연동 시스템 및 방법
KR20090084226A (ko) * 2008-01-31 2009-08-05 주식회사 케이티프리텔 Ｉｍｓ 망 기반의 과금 처리 시스템 및 방법
KR20110023009A (ko) * 2009-08-28 2011-03-08 주식회사 케이티 무선 인터넷 서비스 요금을 과금하기 위한 방법과 이를 위한 이동통신단말
KR20110112280A (ko) * 2008-11-18 2011-10-12 안나 파울라 아메루소 아불라산 전화 통화료 지원 시스템

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6125108A (en) * 1998-04-02 2000-09-26 Siemens Information And Communication Networks, Inc. Method and system for enhanced client identification
JP4263569B2 (ja) * 2003-09-18 2009-05-13 株式会社エヌ・ティ・ティ・ドコモ 通信システム
AU2006255078A1 (en) * 2005-06-06 2006-12-14 Sms.Ac, Inc. Billing system and method for micro-transactions
US20070260556A1 (en) * 2005-06-06 2007-11-08 Michael Pousti System and method for verification of identity for transactions
KR20070005117A (ko) 2005-07-05 2007-01-10 주식회사 인티그리스 코리아 이동통신 요금에서 할인 금액을 적립하여 구성된 모바일펀드를 이용하여 모바일 이익금 환원 서비스를 제공하는방법 및 시스템
US20070244752A1 (en) * 2006-04-17 2007-10-18 Anthony Jeremiah Bayne System and method for the integrated distribution of advertising via the internet and mobile terminals
WO2009063448A2 (en) * 2007-11-13 2009-05-22 Starhome Gmbh Method and system for enabling communication in a hybrid network
US20090265220A1 (en) * 2008-04-18 2009-10-22 Argela Technologies Intelligent multi-channel targeted telecommunications advertisement campaign manager
CN101540980B (zh) * 2009-04-24 2012-03-21 华为技术有限公司 业务优先级更新指示方法、业务优先级更新方法及装置
AU2010256394A1 (en) * 2009-06-04 2012-01-19 Mobile Messenger Global, Inc. Method and system for providing real-time access to mobile commerce purchase confirmation evidence
US8306518B1 (en) * 2009-12-21 2012-11-06 Sprint Communications Company L.P. Handset service migration automation and subscriber identity module tracking
US20110173105A1 (en) * 2010-01-08 2011-07-14 Nokia Corporation Utilizing AAA/HLR infrastructure for Web-SSO service charging
KR101830616B1 (ko) * 2011-07-07 2018-02-21 한국전자통신연구원 이동통신에서 모바일 ｉｐｔｖ 서비스 지역의 동적 구성을 위한 기지국 선택 방법과 그를 위한, 시스템, 장치 및 컴퓨터로 읽을 수 있는 기록매체
KR101929299B1 (ko) * 2011-12-06 2019-03-13 삼성전자주식회사 이동통신 네트워크에서 요금 지불을 대행하는 인터넷 서비스 제공 방법 및 장치
GB2502340B (en) * 2012-05-25 2014-08-06 Ip Access Ltd Network elements, cellular communication system and methods therefor

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006500879A (ja) * 2002-10-12 2006-01-05 エルジー エレクトロニクス インコーポレイティド 無線ｌａｎネットワークと移動通信ネットワークの連動構造における課金情報処理方法
KR100789868B1 (ko) * 2007-06-20 2007-12-28 (주)씨맥스와이어리스 ＩＭＳ망과 휴대 인터넷망(ＷｉＢｒｏ/ＷｉＭＡＸ)간의서비스 품질 연동 시스템 및 방법
KR20090084226A (ko) * 2008-01-31 2009-08-05 주식회사 케이티프리텔 Ｉｍｓ 망 기반의 과금 처리 시스템 및 방법
KR20110112280A (ko) * 2008-11-18 2011-10-12 안나 파울라 아메루소 아불라산 전화 통화료 지원 시스템
KR20110023009A (ko) * 2009-08-28 2011-03-08 주식회사 케이티 무선 인터넷 서비스 요금을 과금하기 위한 방법과 이를 위한 이동통신단말

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3007484A1 (en) * 2014-10-10 2016-04-13 Samsung Electronics Co., Ltd. Method and apparatus for controlling traffic in a wireless communication system
CN105515796A (zh) * 2014-10-10 2016-04-20 三星电子株式会社 无线通信系统中用于控制通信量的方法和装置
US9763229B2 (en) 2014-10-10 2017-09-12 Samsung Electronics Co., Ltd Method and apparatus for controlling traffic in wireless communication system
WO2016076628A3 (ko) * 2014-11-11 2016-07-14 삼성전자 주식회사 이동통신 네트워크를 통한 데이터 서비스 제공 방법 및 장치
US10728836B2 (en) 2014-11-11 2020-07-28 Samsung Electronics Co., Ltd. Method and device for providing data service through mobile communication network
CN105611517A (zh) * 2014-11-18 2016-05-25 三星电子株式会社 用于在移动通信系统的用户设备中提供服务的方法和装置
EP3024210A1 (en) * 2014-11-18 2016-05-25 Samsung Electronics Co., Ltd. Method and apparatus for providing service in user equipment of mobile communication system
US10476687B2 (en) 2014-11-18 2019-11-12 Samsung Electronics Co., Ltd. Method and apparatus for providing service in user equipment of mobile communication system
CN105611517B (zh) * 2014-11-18 2020-12-08 三星电子株式会社 用于在移动通信系统的用户设备中提供服务的方法和装置
WO2016175578A1 (ko) * 2015-04-28 2016-11-03 삼성전자 주식회사 무선 통신 시스템에서 데이터 서비스 제공 방법 및 장치
US10299124B2 (en) 2015-04-28 2019-05-21 Samsung Electronics Co., Ltd. Method and device for providing data service in wireless communication system

Also Published As

Publication number Publication date
US20140348029A1 (en) 2014-11-27
US10033878B2 (en) 2018-07-24
KR101844304B1 (ko) 2018-05-15
KR20130065879A (ko) 2013-06-20

Similar Documents

Publication Publication Date Title
WO2013085314A1 (ko) Ims 기반의 이동통신 네트워크에서 스폰서 서비스 제공 방법 및 시스템
WO2018038490A1 (ko) 무선 통신 네트워크에서 지역별 데이터 네트워크 구성을 위한 방법 및 시스템
WO2016076628A2 (ko) 이동통신 네트워크를 통한 데이터 서비스 제공 방법 및 장치
WO2020231120A1 (ko) 에지 컴퓨팅 서비스에서 단말의 식별자 관리 방법 및 장치
WO2021091225A1 (ko) 통신 시스템에서 네트워크 슬라이스를 이용하여 사용자 장치로 서비스를 제공하기 위한 방법 및 장치
WO2021167277A1 (ko) 에지 컴퓨팅 시스템에서 무선 통신 네트워크 타입에 따른 서비스 제공 장치 및 방법
WO2018143774A1 (en) Registration management method for terminal accessing 5g network on non-3gpp access
WO2013009008A1 (en) Method and terminal for performing detach procedure
WO2011056034A2 (en) Method for controlling session and server using the same
WO2021091232A1 (ko) 이동통신 시스템에서 어플리케이션 서버의 정보 제공 장치 및 방법
WO2011014015A2 (ko) 무선 통신 시스템에서 단말에게 통신 서비스를 제공하는 방법 및 이를 위한 장치
WO2015005651A1 (en) Lawful interception method and apparatus of d2d communication-capable terminal
WO2012081882A2 (ko) 이동통신 시스템에서 셀 방송 기술을 이용한 신뢰성 있는 그룹 멀티캐스트 전송 방법 및 장치
WO2010062139A2 (en) Method and apparatus for controlling session for interworking in converged ip messaging service and system thereof
EP3566509A1 (en) Registration management method for terminal accessing 5g network on non-3gpp access
WO2021091307A1 (ko) 무선 통신 시스템에서 mbs 서비스 제공에 대한 mbs 서비스 세션의 설정을 위한 장치 및 방법
WO2021066452A1 (ko) 5g 사용자 활성화 방법 및 장치
KR20030040099A (ko) 정보 삽입 서비스 제공 시스템, 정보 삽입 방법, 통신네트워크, 정보 관리 장치 및 서비스 제어 장치
WO2010064866A2 (en) Iptv service provision method and system for fixed and mobile devices
WO2018038412A1 (ko) 차세대 네트워크에서 복수의 액세스를 통해 접속을 수행하는 방법 및 사용자 장치
WO2013085312A1 (ko) 이동통신 네트워크에서 요금 지불을 대행하는 인터넷 서비스 제공 방법 및 장치
WO2013105816A1 (ko) 무선통신 시스템에서 서비스 도메인을 선택하는 방법 및 장치
EP3504864A1 (en) Method for managing short data service (sds) in mission critical data (mc data) communication system
WO2014030893A1 (ko) 단말 장치에 내장되어 설치되는 가입자 인증 모듈의 프로파일 관리 방법 및 이를 이용하는 가입자 인증 장치
WO2023075214A1 (en) Method and apparatus for supporting edge computing service for roaming ue in wireless communication system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12854816

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14363772

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 12854816

Country of ref document: EP

Kind code of ref document: A1