KR100946909B1 - Apparatus and method for performing an interface in a communication network - Google Patents

Abstract

The present invention receives, in a communication network, an event to be processed using information managed by a second system that provides a second service from a first system that provides a first service, and the second system receives the information. Use the interface to perform an action corresponding to the event.

Mobile communication system, Internet service / content providing system, service interface server

Description

Apparatus and method for performing an interface in a communication network {APPARATUS AND METHOD FOR PERFORMING AN INTERFACE IN A COMMUNICATION NETWORK}

1 is a diagram illustrating a communication network structure for performing an interface between a mobile communication system and an Internet service / content providing system according to an embodiment of the present invention.

2 illustrates an interface type performed by the SI server 164 of FIG. 1.

3 is a signal flow diagram schematically illustrating an operation of retrieving location information of the MS 170 in response to a request of an application server 200 in the communication network of FIG. 2.

4 is a signal flow diagram schematically illustrating an operation of tracking a location of an MS according to a request of an application server 200 in the communication network of FIG. 2.

5 is a signal flow diagram schematically illustrating an operation of searching for a device capability of an MS in accordance with a request of an application server 200 in the communication network of FIG. 2.

6 is a signal flow diagram schematically illustrating an operation of retrieving a user profile of an MS in response to a request of an application server 200 in the communication network of FIG. 2.

FIG. 7 is a signal flowchart schematically illustrating an operation of performing paging of an MS according to a request of an application server 200 in the communication network of FIG. 2.

8 is a signal flow diagram schematically illustrating an operation of providing a QoS-based Internet service according to a request of an application server 200 in the communication network of FIG. 2.

9 is a diagram illustrating an internal structure of the SI server 164 of FIG. 2.

FIG. 10 shows an internal information structure of the message routing database 913 of FIG.

FIG. 11 is a diagram showing an internal information structure of the transaction log database 911 of FIG.

12 is a flowchart illustrating an operation process of the SI server 164 of FIG. 2.

13a and 13b schematically illustrate a message format transmitted and received in the communication network of FIG.

14A and 14B show an internal structure of the charging server 169 of FIG.

FIG. 15 shows the internal information structure of the application server charging database 1411 of FIGS. 14A and 14B.

FIG. 16 is a flowchart illustrating an operation process of the charging server 169 of FIG. 2.

The present invention relates to an apparatus and a method for performing an interface in a communication network, and more particularly, to an apparatus and a method for performing an interface between a mobile communication system and an internet service / content providing system.

In general, mobile communication systems are being developed in the form of providing various services to mobile terminals (hereinafter referred to as MSs). In other words, the mobile communication system is developing to provide various services such as Internet services and Internet contents to MSs. Here, the Internet service and the Internet content are provided in an Internet service / content providing system.

However, at present, the mobile communication system and the Internet service / content providing system operate independently. Since the mobile communication system and the Internet service / content providing system operate independently of each other, the mobile communication system cannot use the information related to the Internet service / content managed by the Internet service / content providing system, and the Internet service / content In the providing system, the mobile communication related information managed by the mobile communication system cannot be used. As such, since the mobile communication system cannot use the information related to the Internet service / content managed by the Internet service / content providing system, there is a limit to the service that can be provided, and the Internet service / content providing system also manages Since there is no information related to a mobile communication service, there is a limit to the service that can be provided.

Accordingly, the present invention proposes an apparatus and method for performing an interface in a communication network.

In addition, the present invention proposes an apparatus and method for performing an interface between a mobile communication system and an Internet service / content providing system.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be noted that in the following description, only parts necessary for understanding the operation according to the present invention will be described, and descriptions of other parts will be omitted so as not to distract from the gist of the present invention.

The present invention proposes an apparatus and method for performing an interface in a communication network. In the present invention, an apparatus and method for performing an interface between a mobile communication system and an internet service / contents providing system will be described as an example. Of course, the present invention can be applied not only to an internet service / content providing system but also to performing an interface between two systems providing different services.

The device proposed in the present invention; An apparatus for performing an interface in a communication network, the apparatus comprising: receiving an event to be processed using information managed by a second system that provides a second service from a first system that provides a first service, and the second system receives the event. And a service interface server for performing an interface to perform an operation corresponding to the event using the information.

The method proposed in the present invention; A method of performing an interface in a communication network, the method comprising: receiving an event to be processed by using information managed by a second system providing a second service from a first system providing a first service, and the second system And performing an interface to perform an operation corresponding to the event using this information.

1 is a diagram illustrating a communication network structure for performing an interface between a mobile communication system and an Internet service / content providing system according to an embodiment of the present invention.

Referring to FIG. 1, the communication network includes an Internet service / content providing system 100, a mobile communication system 160, a mobile station (MS) 170, Examples include a personal computer (PC) such as a laptop, a personal digital assistant (PDA), a portable multimedia player (PMP), and a camera. Here, the Internet service / content providing system 100 and the mobile communication system 160 are connected through the Internet 130. Hereinafter, for convenience of description, the MS will be referred to as a user or subscriber.

The Internet service / content providing system 100 includes application servers for providing various Internet services / content, and in FIG. 1, the Internet service / content providing system 100 uses the Internet as its application servers. A protocol television (IPTV: Internet Protocol Television, hereinafter referred to as 'IPTV') server 101, a music / video streaming server 102, a search server Assume that 103 is included, and an advertising server 104 is included. The IPTV server 101 provides an IPTV service, the music / video streaming server 102 provides a music / video streaming service, the search server 103 provides a search service, and the advertisement server ( 104 provides an advertising service.

In addition, the mobile communication system 160 includes a radio access system (RAS) 161 and an access service network gateway (ASN GW). GW '162, a core service network (CSN: hereinafter referred to as' CSN') 163, and a service interface (SI: hereinafter referred to as' SI '). Server 164, location information server 165, device capability server 166, user profile server 167, and quality of service. (QoS: Quality of Service, hereinafter referred to as 'QoS') A server 168 and a billing server (169) is included. The SI server 164 may also be referred to as a universal service interface (USI) server. In FIG. 1, a case where the SI server 164 is implemented as a separate device is described as an example. However, the SI server 164 may be implemented as an internal unit of the ASN GW 162 or the CSN 163. Of course.

Since the RAS 161, the ASN GW 162, and the CSN 163 are the same as the RAS, the ASN GW, and the CSN of a general mobile communication system, detailed descriptions thereof will be omitted. Since the SI server 164 performs an interface between the Internet service / content providing system 100 and the mobile communication system 160, an interface type performed by the SI server 164 will be described in detail below. The detailed description thereof will be omitted here.

The location information server 165 manages location information of the MS 170. The device capability server 166 manages information about device capabilities of the MS 170. Here, the device capability information includes a type of the MS 170, a resolution that the MS 170 can provide, information on whether a codec is supported, and the like. The user profile server 167 manages user profiles, the QoS server 168 manages information related to QoS that must be provided to the MS 170, and the billing server 169 manages the MS 170 or Internet service / The billing information for the content providing system 100 is managed.

Next, an interface type performed by the SI server 164 of FIG. 1 will be described with reference to FIG. 2.

FIG. 2 illustrates an interface type performed by the SI server 164 of FIG. 1.

As shown in FIG. 2, the SI server 164 performs nine interface types in total, and each of the nine interface types will be described in detail as follows.

(1) U0 interface (U0 I / F: U0 Interface, hereinafter referred to as 'U0 I / F')

U0 I / F is an interface between the MS 170 and the SI server 164 and uses the HTTP / XML (eXtensible Markup Language) protocol as its protocol. In addition, the function of the U0 I / F (function, hereinafter referred to as "function") is as follows.

<function>

User requested network information request / report requested by MS 170

(2) U1 interface (U1 I / F: U1 Interface, hereinafter referred to as 'U1 I / F')

U1 I / F is an interface between any application server 200 included in the Internet service / content providing system 100 and the SI server 164, and uses the HTTP / XML protocol as its protocol. In addition, the function of the U1 I / F is as follows.

<function>

Content access authorization

User / Device Information Retrieval

Subscriber location information retrieval

QoS requirements enforcement

Accounting information exchange

Server triggered paging transaction

The function of the U1 I / F will be described in detail below.

First, the content access authorization function will be described.

The content access authorization function is a function defining an authentication procedure between the application server 200 and the SI server 164. The authentication procedure between the application server 200 and the SI server 164 is performed as follows.

The application server 200 transmits an authentication request message to the SI server 164. The SI server 164 performs authentication with respect to the application server 200 in response to the authentication request message, and responds to the authentication request message to the application server 200 in accordance with a result of the authentication. Send an authentication response message which is a message. Here, the authentication request message includes fields as shown in Table 1 below.

As shown in Table 1, the authentication request message includes an ISPname field, an Account field, and a Password field, and the data type of each field is a string. In addition, ISPname represents the name of the application server 200 that has requested authentication to the SI server 164, Account represents the subscriber's account, Password represents the subscriber's password. In addition, the authentication response message includes fields as shown in Table 2 below.

As shown in Table 2, the authentication response message includes a resultCode field, and the data type of the resultCode field is an integer. The resultCode indicates a result of authentication performed by the SI server 164, that is, success or failure. For example, the resultCode indicates success and a value of 2 indicates a failure.

Second, the subscriber location information search function will be described.

The subscriber location information retrieval function is a function for defining a subscriber location information retrieval procedure between the application server 200 and the SI server 164. The subscriber location information retrieval procedure between the application server 200 and the SI server 164 is performed as follows.

The application server 200 transmits a location information request (LocationInfo Request) message for requesting the subscriber's location information search to the SI server 164. The SI server 164 receives a location information request message from the application server 200 and retrieves the location information of the subscriber in response to the location information request message. The SI server 164 transmits the searched subscriber's location information to the application server 200 by including the location information response message, which is a response message to the location information request message. Here, the location information request message includes fields as shown in Table 3 below.

As shown in Table 3, the location information request message includes a userIDtype field, a userID field, a requestType field, and a ChargingFlag field. The data type of the userIDtype field, the userID field, and the requestType field is a string, and the data type of the ChargingFlag field is a number. Here, the userIDtype represents the IP address of the subscriber, the userID represents the identifier (ID) of the subscriber (hereinafter, referred to as 'ID'), and the requestType represents a service classification and may be represented as Immediate or Delay. In this case, Immediate means emergency service and is processed first because it has higher priority than Delay service. Delay is processed when there is no immediate service request.

ChargingFlag is a flag indicating the object of charging. Here, when the value of ChargingFlag is set to 1 as an example, it indicates that the charging target is the application server 200. When the value of ChargingFlag is set to 2 as an example, it indicates that the charging target is a subscriber.

In addition, the location information response message includes fields as shown in Table 4 below.

As shown in Table 4, the location information response message includes a geographicInfo field, and the data type of the geographicInfo field is a string. Here, the geographicInfo represents information about the area where the subscriber is located.

Third, the user / device information retrieval function will be described.

The user / device information search function is a function for defining a user / device information search procedure between the application server 200 and the SI server 164. A user / device information retrieval procedure between the application server 200 and the SI server 164 is performed as follows.

The application server 200 transmits a device information request message to the SI server 164. The SI server 164 retrieves device information of a corresponding subscriber as it receives a device information request message from the application server 200. The SI server 164 transmits the searched device information to the application server 200 by including the retrieved device information in a device information response message, which is a response message to the device information request message. Here, the device information request message includes the fields shown in Table 5 below.

As shown in Table 5, each field included in the device information request message and its data type are the same as described in Table 3, and thus detailed description thereof will be omitted.

In addition, the device information response message includes the fields shown in Table 6 below.

As shown in Table 6, the device information response message includes a deviceType field, a deviceVendor field, a deviceModel field, a deviceOSVersion field, a dviceTotalMemory field, a deviceFreeMemory field, a deviceResolution field, a MACAddress field, an IPAddress field, and a phoneNumber. Field, connectivitySupported field, currentConnectivity field, defaultWebBrowserType field, and defaultWebBrowserVersion field. The data type of all fields included in the Diabis Information Response message is a string. The fields included in the device information response message will be described below.

(1) deviceType field

The deviceType indicates the type of the MS, and the type of the MS is, for example, a PDA, a personal computer, a PMP, a camera, or the like.

(2) deviceVendor field

deviceVendor represents the vendor of the MS.

(3) deviceModel field

deviceModel represents model information of the corresponding MS.

(4) deviceOSVersion field

deviceOSVersion represents version information of an operating system (OS) used by a corresponding MS.

(5) deviceTotalMemory field

deviceTotalMemory represents the total memory size of the MS.

(6) deviceFreeMemory field

deviceFreeMemory indicates the amount of memory currently available to the MS.

(7) deviceResolution field

deviceResolution indicates the resolution of the corresponding MS.

(8) MACAddress field

MACAddress represents a medium access control (MAC) address of a corresponding MS.

(9) IPAddress field

IPAddress represents the current IP address of the corresponding MS.

(10) field phoneNumber

phoneNumber represents the phone number of the corresponding MS.

(11) connectivitySupported field

connectivitySupported indicates the connectivity available to the MS. The connectivity may be Bluetooth, 802.11, or the like.

(12) currentConnectivity field

currentConnectivity indicates the connectivity currently available to the MS.

(13) defaultWebBrowserType field

defaultWebBrowserType represents the default web browser type of the MS.

(14) defaultWebBrowserVersion field

defaultWebBrowserVersion represents the default web browser version of the MS.

Fourth, the QoS request execution function will be described.

The QoS request execution function is a function defining a QoS request execution procedure between the application server 200 and the SI server 164. The QoS request execution procedure between the application server 200 and the SI server 164 is performed as follows.

The application server 200 transmits to the SI server 164 a QoS Policy Request message requesting a QoS policy for the subscriber. The SI server 164 retrieves the QoS policy for the subscriber as it receives the QoS policy request message from the application server 200. The SI server 164 transmits the QoS policy result to the application server 200 by including the QoS policy result in a QoS policy response message, which is a response message to the QoS policy request message. Here, the QoS policy request message includes the fields shown in Table 7 below.

As shown in Table 7, the QoS policy request message includes a Session ID field, a UserIDtype field, a UserID field, a requestType field, an srcIPAddress field, an srcPort field, a destIPAddress field, a destPort field, a serviceType field, It includes a direction field and a Charging Flag field. Among the fields shown in Table 6, the data type of the Session ID field, the srcPort field, the destPort field, and the Charging Flag field is numeric, and the data types of the remaining fields are strings. Here, Session ID indicates the ID of the corresponding session, and requestType type includes two types, Reserved and Terminated. In case of Reservered, it means a message requesting to start QoS service, and in Terminated, ending QoS service. It means the request message. In addition, in Table 7, srcIPAddress represents an IP address of an application server 200 providing a service, srcPort represents a port of an application server 200 providing a service, and destIPAddress represents an IP address of a corresponding subscriber. DestPort represents a port of a corresponding subscriber, serviceType represents a type of service provided (for example, a VoD service or an IPTV service), and a direction indicates a QoS support direction (for example, uplink only), Downlink only, both uplink and downlink).

In addition, the QoS policy response message includes the fields shown in Table 8 below.

As shown in Table 8, the QoS policy response message includes a ResultCode field, and the data type of the ResultCode field is an integer. Here, ResultCode indicates whether a QoS policy for the QoS policy request message can be provided, and information of success or failure. For example, if the ResultCode value is 1, it indicates success, and if it is 2, it indicates failure.

Fifth, the server trigger paging transaction function will be described.

The server trigger paging transaction function is a function defining a server trigger paging transaction procedure between the application server 200 and the SI server 164. The server trigger paging transaction procedure between the application server 200 and the SI server 164 is performed as follows.

The application server 200 transmits a service alert request message requesting paging for the subscriber to the SI server 164. The SI server 164 searches for whether paging is possible for the corresponding subscriber as the service alert request message is received from the application server 200. The SI server 164 transmits the searched paging search result to the application server 200 in the service alert response message which is a response message to the service alert request message. Here, the service alert request message includes fields as shown in Table 9 below.

As shown in Table 9, the service alert request message includes a userIDType field, a userID field, a calleeIDType field, a calleeID field, an applicationType field, and a ChargingFlag field. The data type of the userIDType field, the userID field, the calleeIDType field, the calleeID field, and the applicationType field is a string, and the data type of the ChargingFlag field is a number. Here, userIDType represents an IP address of a subscriber requesting paging, userID represents an ID of a subscriber requesting paging, calleeIDType represents an IP address of a subscriber receiving paging, and calleeID represents an ID of a subscriber receiving paging. ApplicationType represents the type of messenger used.

In addition, the service alert response message includes the fields shown in Table 10 below.

As shown in Table 10, the service alert response message includes a ResultCode field, and the data type of the ResultCode field is an integer. Here, ResultCode indicates whether paging for the service alert request message can be provided and indicates information of success or failure. For example, if the ResultCode value is 1, it indicates success, and if it is 2, it indicates failure.

(3) U2 interface (U2 I / F: U2 Interface, hereinafter referred to as 'U2 I / F')

U2 I / F is an interface between the SI server 164 and the ASN GW 162, and the protocol is HyperText Transfer Protocol (HTTP) / XML protocol or Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) protocol or DIAMETER / Use the RADIUS (Remote Authentication Dial-In User Services) protocol. In addition, the function of the U2 I / F is as follows.

<function>

Subscriber location information request / response

Paging feature triggering

Requested QoS enforcement request / response

Guaranteed QoS matrix report

Presence information request / response

Provisioning

(4) U3 interface (U3 I / F: U3 Interface, hereinafter referred to as 'U3 I / F')

The U3 I / F is an interface between the SI server 164 and the CSN 163 and uses the HTTP / XML protocol or the DIAMETER / RADIUS (Remote Authentication Dial-In User Services) protocol. In addition, the function of the U3 I / F is as follows.

<function>

IP layer information transaction (IP: Internet Protocol, hereinafter referred to as 'IP')

IP level paging feature triggering

Requested QoS enforcement request / response

Content inspection triggering

Content aggregation / addition triggering

(5) Billing Interface (hereinafter referred to as "Billing Interface")

The billing interface is an interface between the SI server 164 and the charging server 169, and uses the HTTP / XML protocol or the DIAMETER / RADIUS protocol as the protocol. In addition, the function of the billing interface is as follows.

<function>

Pre / Post-pay accounting transaction

Accounting record transaction

(6) User profile interface (hereinafter referred to as 'User_Profile Interface')

The User_Profile Interface is an interface between the SI server 164 and the user profile server 167. The protocol uses HTTP / XML protocol or DIAMETER / RADIUS protocol. In addition, the function of the User_Profile Interface is as follows.

<function>

Service authentication / authorization request / response

Service profile request / response

Subscriber profile request / response

(7) Device capability interface (hereinafter, referred to as "device_capability interface")

The Device_Capability Interface is an interface between the SI server 164 and the device capability server 166, and uses the HTTP / XML protocol or the DIAMETER / RADIUS protocol as the protocol. In addition, the function of the Device_Capability Interface is as follows.

<function>

Device profile request / response

(8) Location Information Interface (Location_Information Interface, hereinafter referred to as 'Location_Information Interface')

The Location_Information Interface is an interface between the SI server 164 and the location information server 165 and uses TCP / UDP as its protocol. In addition, the function of the Location_Information Interface is as follows.

<function>

User or Device location information request / response

(9) QoS interface (hereinafter referred to as 'QoS Interface')

The QoS Interface is an interface between the SI server 164 and the QoS server 168. The protocol uses HTTP / XML protocol or DIAMETER / RADIUS protocol. In addition, the function of the QoS Interface is as follows.

<function>

User / Device / Service QoS information request / response

QoS decision functionality

Next, referring to FIG. 3, an operation of searching for location information of the MS 170 in response to a request of the application server 200 in the communication network of FIG. 2 will be described.

3 is a signal flow diagram schematically illustrating an operation of retrieving location information of the MS 170 in response to a request of an application server 200 in the communication network of FIG. 2.

Referring to FIG. 3, the application server 200 first identifies a location information request message (hereinafter, referred to as a 'location information request message') including an ID of an MS to search for location information. (Step 311). Here, the MS ID included in the Location Info Request message may be a user ID or a device ID. The SI server 164 transmits a Location Info Request message to the location information server 165 in response to receiving a Location Info Request message from the application server 200 (step 313).

When the location information server 165 receives a Location Info Request message from the SI server 164, the location information server 165 retrieves location information of the MS corresponding to the ID of the MS included in the Location Info Request message. The location information server 165 includes the location information (Geographical-Location-Information) of the searched MS in a location information result message (hereinafter, referred to as a 'Location Info Result message'). (Step 315). The SI server 164 transmits the Location Info Result message received from the location information server 165 to the application server 200 as it is (step 317).

As described above, since the location information on the MS is retrieved at the request of the application server 200, the application server 200 must provide the mobile communication system 160 with the fee for the location information search. Accordingly, the application server 200 includes a transaction fee that includes fee payment information (hereinafter, referred to as 'Authorized-Bill-Token') for location information searched by itself, that is, authorized and searched by the application server 200. A token message (hereinafter referred to as a "transaction bill token message") is transmitted to the SI server 164 (step 319). Herein, the transaction indicates an event to be processed, and a transaction bill token message transmission process may be performed optionally. This is because the charging server 169 may store the charging information at the time when the location information server 165 transmits a Location Info Result message to the SI server 164.

Upon receipt of the Transaction Bill Token message, the SI server 164 transmits a transaction charging request message (hereinafter, referred to as a "Transaction Billing Request message") to the charging server 169. In this case, the Transaction Billing Request message is an Internet Service Provider (ISP) of the application server 200 that has searched for location information on the MS, an application server ID or an Internet content provider (ICP). Internet Contents Provider, hereinafter referred to as 'ICP'. Includes application server ID and billing-info. In addition, the charging server 169 stores the charging information. (Step 321). In the present invention, a case of charging based on the ID of the application server 200 will be described as an example, but the mobile communication system 160 charges all application servers in the mobile communication system 160. Since it may be integrated collectively, the charge may be based on the ID of the mobile communication system 160 itself, that is, the ISP / ICP ID, rather than the ID of the application server 200.

Next, referring to FIG. 4, the operation of tracking the location of the MS according to the request of the application server 200 in the communication network of FIG. 2 will be described.

4 is a signal flowchart schematically illustrating an operation of tracking the location of an MS according to a request of an application server 200 in the communication network of FIG. 2.

Referring to FIG. 4, the application server 200 first transmits a location tracking request message (hereinafter, referred to as a 'location tracking request message') including an ID of an MS to track a location to the SI server 164. Transmit (step 411). Here, the MS ID included in the Location Tracking Request message may be a user ID or a device ID. In addition, the Location Tracking Request message includes not only the ID of the MS, but also information on a period for tracking a location, and an accuracy of a required location tracking. When the SI server 164 receives the Location Tracking Request message from the application server 200, the SI server 164 transmits the received Location Tracking Request message to the location information server 165 as it is (step 413).

When the location information server 165 receives a Location Tracking Request message from the SI server 164, the location information server 165 retrieves location information of the MS corresponding to the ID of the MS included in the Location Tracking Request message. The location information server 165 includes the location information (Geographical-Location-Information) of the searched MS in a location report message (hereinafter referred to as a location report message) to the SI server 164. Transmit (step 415). The SI server 164 transmits the Location Report message received from the location information server 165 to the application server 200 as it is (step 417). The location information server 165 transmits the location information of the MS searched for the period corresponding to the period information included in the Location Tracking Request message to the SI server 164 through a Location Report message. The server 164 transmits the received Location Report message to the application server 200 (steps 419, 421, 423 and 425). Of course, if the location tracking is to be terminated even before the period corresponding to the period information ends, the application server 200 may transmit a Location Tracking Request message to the SI server 164 again. The period information is set to '0' (step 427). In this case, the SI server 164 also transmits to the location information server 165 a location tracking request message, which is received from the application server 200 and the period information is set to 0 (step 428).

As described above, since the location of the MS is tracked according to the request of the application server 200, the application server 200 must provide the mobile communication system 160 with the fee for the location tracking. Accordingly, the application server 200 transmits, to the SI server 164, a Transaction Bill Token message including an Authorized-Bill-Token with respect to the location information authorized and tracked by the application server 200 (step 429). In this case, the Transaction Bill Token message transmission process is also optionally performed. This is because the charging server 169 may store the charging information at the time when the location information server 165 transmits a Location Report message to the SI server 164.

The SI server 164 transmits a Transaction Billing Request message to the billing server 169 in response to receiving the Transaction Bill Token message. Here, the Transaction Billing Request message includes the ISP / ICP application server ID and billing information of the application server 200 that has searched for the location information on the MS. In addition, the charging server 169 stores the charging information (step 431).

Next, referring to FIG. 5, an operation of searching for a device capability of the MS according to a request of the application server 200 in the communication network of FIG. 2 will be described.

FIG. 5 is a signal flow diagram schematically illustrating an operation of searching for a device capability of an MS according to a request of an application server 200 in the communication network of FIG. 2.

Referring to FIG. 5, first, the application server 200 transmits a device information request message (hereinafter, referred to as a 'device info request message') including an ID of an MS to search for device capability. (Step 511). Here, the MS ID included in the Device Info Request message may be a user ID or a device ID. When the SI server 164 receives the Device Info Request message from the application server 200, the SI server 164 transmits the received Device Info Request message to the device capability server 166 as it is (step 513).

When the device capability server 166 receives the Device Info Request message from the SI server 164, the device capability server 166 retrieves the device capability of the MS corresponding to the ID of the MS included in the Device Info Request message. The device capability server 166 may include device-capability-information information of the searched MS in a device information result message (hereinafter, referred to as a “device info result message”). Transmit to server 164 (step 515). The SI server 164 transmits the Device Info Result message received from the device capability server 166 to the application server 200 as it is (step 517).

As described above, since the device capability for the MS has been retrieved according to the request of the application server 200, the application server 200 must provide the mobile communication system 160 with a fee for the device capability search. Accordingly, the application server 200 transmits a Transaction Bill Token message including the Authorized-Bill-Token for the device capability that the application server 200 grants the authority to the SI server 164 (step 519). In this case, the Transaction Bill Token message transmission process is also optionally performed. This is because the charging server 169 may store the charging information at the time when the device capability server 166 transmits a Device Info Result message to the SI server 164.

The SI server 164 transmits a Transaction Billing Request message to the billing server 169 in response to receiving the Transaction Bill Token message. Here, the Transaction Billing Request message includes the ISP / ICP application server ID and the billing information, which has searched for the device capability of the MS. In addition, the charging server 169 stores the charging information (step 521).

Next, referring to FIG. 6, an operation of searching for a user profile of the MS according to a request of the application server 200 in the communication network of FIG. 2 will be described.

FIG. 6 is a signal flowchart schematically illustrating an operation of searching for a user profile of an MS according to a request of an application server 200 in the communication network of FIG. 2.

Referring to FIG. 6, the application server 200 first identifies a user profile request message (hereinafter, referred to as a 'user profile request message') including an ID of an MS to search for a user profile. (Step 611). Here, the MS ID included in the User Profile Request message may be a user ID. When the SI server 164 receives the User Profile Request message from the application server 200, the SI server 164 transmits the received User Profile Request message to the user profile server 167 as it is (step 613).

When the user profile server 167 receives a User Profile Request message from the SI server 164, the user profile server 167 searches for a user profile of the MS corresponding to the ID of the MS included in the User Profile Request message. In addition, the user profile server 167 includes the user profile (User-Profile-Information) of the searched MS in a user profile result message (hereinafter, referred to as a 'user profile result message'). (Step 615). The SI server 164 transmits the User Profile Request message received from the user profile server 167 to the application server 200 as it is (step 617).

As described above, since the user profile for the MS has been searched according to the request of the application server 200, the application server 200 must provide the mobile communication system 160 with a fee for searching for the user profile. Accordingly, the application server 200 transmits a Transaction Bill Token message including an Authorized-Bill-Token for the user profile that the application server 200 has authorized and retrieved to the SI server 164 (step 619). In this case, the Transaction Bill Token message transmission process is also optionally performed. This is because the charging server 169 may store the charging information at the time when the user profile server 167 transmits a User Profile Request message to the SI server 164.

The SI server 164 transmits a Transaction Billing Request message to the billing server 169 in response to receiving the Transaction Bill Token message. In this case, the Transaction Billing Request message includes the ISP / ICP application server ID and the billing information which searched the user profile for the MS. In addition, the charging server 169 stores the charging information (step 621).

Next, an operation of performing paging of the MS according to the request of the application server 200 in the communication network of FIG. 2 will be described with reference to FIG. 7.

FIG. 7 is a signal flowchart schematically illustrating an operation of performing paging of an MS according to a request of an application server 200 in the communication network of FIG. 2.

Referring to FIG. 7, the application server 200 first transmits a paging request message (hereinafter, referred to as a 'paging request message') including an ID of an MS to request paging to the SI server 164. (Step 711). Here, the MS ID included in the paging request message may be a user ID or a device ID, and the paging request message includes paging information (paging-info) for the MS. The SI server 164 transmits the received Paging Request message to the ASN GW 162 as it receives the Paging Request message from the application server 200 (step 713).

When the ASN GW 162 receives the Paging Request message from the SI server 164, the ASN GW 162 performs paging for the MS corresponding to the ID of the MS included in the Paging Request message (Paging to User / Device, Response). from User / Device) (steps 715 and 717). The ASN GW 162 transmits the paging result information (Paging-Response-Info) to the SI server 164 by including a paging response message (hereinafter, referred to as a 'paging response message'). (Step 719). The SI server 164 transmits the paging response message received from the ASN GW 162 to the application server 200 as it is (step 721).

As described above, since the paging is performed for the MS according to the request of the application server 200, the application server 200 must provide a fee for the paging request to the mobile communication system 160. Accordingly, the application server 200 transmits a Transaction Bill Token message including an Authorized-Bill-Token for paging requested by the application server 200 to the SI server 164 (step 723). In this case, the Transaction Bill Token message transmission process is also optionally performed. This is because the charging server 169 may store the charging information at the time when the ASN GW 162 transmits a paging response message to the SI server 164.

The SI server 164 transmits a Transaction Billing Request message to the billing server 169 in response to receiving the Transaction Bill Token message. In this case, the Transaction Billing Request message includes the ISP / ICP application server ID and billing information that has requested paging to the MS. In addition, the charging server 169 stores the charging information (step 725).

Next, a description will be given of an operation of providing QoS-based Internet service according to a request of the application server 200 in the communication network of FIG. 2 as follows.

FIG. 8 is a signal flowchart schematically illustrating an operation of providing a QoS based Internet service according to a request of an application server 200 in the communication network of FIG. 2.

Referring to FIG. 8, first, the application server 200 calls a service QoS request message (hereinafter, referred to as a 'Service QoS Request message') including an ID of an MS requesting to provide a QoS based Internet service. Transmit to SI server 164 (step 811). Here, the MS ID included in the Service QoS Request message may be a user ID or a device ID, and the Service QoS Request message is information on a QoS level that the MS wants to be guaranteed in the Internet service (Service-QoS-Info). ) Too. When the SI server 164 receives the Service QoS Request message from the application server 200, the SI server 164 transmits the received Service QoS Request message to the QoS server 168 as it is (step 813).

When the QoS server 168 receives the Service QoS Request message from the SI server 164, the QoS server 168 provides information about the MS ID included in the Service QoS Request message and the QoS level that the MS wants to be guaranteed in the Internet service. With reference to this, the MS determines QoS allocation information (QoS-Assignment-Info) required for receiving an Internet service at a desired QoS level. Here, the QoS allocation information includes TCP / UDP port information, assigned QoS level information, and the like. The QoS server 168 transmits the determined QoS assignment information to the SI server 164 by including it in a service QoS assignment message (hereinafter, referred to as a 'service QoS assignment message') (step 815). The SI server 164 transmits the Service QoS Assignment message received from the QoS server 168 to the application server 200 as it is (step 817).

Upon receiving the Service QoS Assignment message, the application server 200 provides the Internet service in a form of guaranteeing the QoS requested by the MS to the corresponding MS corresponding to the QoS assignment information included in the Service QoS Assignment message ( QoS guaranteed IP service) (step 819).

As described above, since the QoS-based Internet service is performed for the MS according to the request of the application server 200, the application server 200 charges a fee for performing the QoS-based Internet service. Must be provided). Accordingly, the application server 200 transmits a Transaction Bill Token message including an Authorized-Bill-Token for a QoS-based Internet service performed by the application server 200 to the SI server 164 (step 821). . In this case, the Transaction Bill Token message transmission process is also optionally performed. This is because the charging server 169 may store the charging information at the time when the QoS server 168 transmits a Service QoS Assignment message to the SI server 164.

The SI server 164 transmits a Transaction Billing Request message to the billing server 169 in response to receiving the Transaction Bill Token message. In this case, the Transaction Billing Request message includes the ISP / ICP application server ID and the billing information that requested the QoS-based Internet service to the MS. In addition, the charging server 169 stores the charging information (step 823).

Next, an internal structure of the SI server 164 will be described with reference to FIG. 9.

9 is a diagram illustrating an internal structure of the SI server 164 of FIG. 2.

Referring to FIG. 9, the SI server 164 includes a transaction log database 911, a message routing database 913, a controller 915, and an input line. A line interface unit 917 and an output line interface unit 919.

The input line interface unit 917 and the output line interface unit 919 provide an interface between the application server 200 and the mobile communication system 160. In addition, when the message routing database 913 receives a specific event from the application server 200, it is necessary to transmit the received event to a corresponding server in the mobile communication system 160. . Since an internal information structure of the message routing database 913 will be described in detail later, a detailed description thereof will be omitted.

In addition, the transaction log database 911 is required to transmit a response received from an internal server of the mobile communication system 160 to the application server 200 in response to an event from the application server 200. . Since the internal information structure of the transaction log database 911 will be described in detail below, a detailed description thereof will be omitted.

Next, an internal information structure of the message routing database 913 will be described with reference to FIG. 10.

FIG. 10 illustrates an internal information structure of the message routing database 913 of FIG.

10, when the SI server 164 receives a specific event from an application server 200, the message routing database 913 transmits the received event to the mobile communication system 160. Required to send to the server. That is, when the SI server 164 receives a specific event from the application server 200, the SI server 164 analyzes the specific event, and accordingly, the internal event to which the specific event in the mobile communication system 160 should be delivered. Determine the server. The specific event must be delivered to the determined internal server. In this case, the SI server 164 transmits the specific event to the determined internal server with reference to the message routing database 913.

Referring to FIG. 10, the message routing database 913 includes a server name area (hereinafter referred to as a server name area) and a serviced user / device range area (hereinafter, referred to as a 'serviced user / device range'). Area ”) and other information areas (hereinafter referred to as“ other information areas ”).

The Server Name area is an area indicating a server name corresponding to a server in the mobile communication system 160, and may represent an address of the internal server instead of a server name. Meanwhile, the mobile communication system 160 may implement a plurality of specific servers when it is impossible to perform all the functions required by one specific server therein. In this case, if the specific server is one, the value of the Serviced User / Device Range area is described as' ALL '. If the specific server is plural, for example, two, the value of the Serviced User / Device Range area is' ODD 'or' EVEN '. In addition, in the Other Information area, additional information required for each internal server is described.

Next, an internal information structure of the transaction log database 911 will be described with reference to FIG. 11.

FIG. 11 is a diagram illustrating an internal information structure of the transaction log database 911 of FIG.

Before describing FIG. 11, the transaction log database 911 receives a response received from an internal server of the mobile communication system 160 in response to an event from an application server 200. It is necessary to send by. That is, as the SI server 164 receives a specific event from the application server 200, the application server 200 receives a response received from the internal server in response to the specific event transmitted to the internal server of the mobile communication system 160. Information about the specific event is stored in the transaction log database 911 before being transmitted to.

Referring to FIG. 11, the transaction log database 911 includes a transaction code area (hereinafter referred to as a 'transaction code area') and an ICP / ICP application server name area (hereinafter, 'ISP / ICP A /'. S Name area '), Server Name area, and Other Inforamtion area. In the Transaction Code area, a transaction code mapped to each specific event received from the application server 200 is described. The transaction code is assigned every time an event occurs, and a response to the event is transmitted to the application server 200. Is maintained until. In addition, the transaction code may be explicitly described in all messages transmitted and received between the application server 200, the SI server 164, and the corresponding internal server in the mobile communication system 160, or the SI Of course, only the server 164 can be managed. In the ISP / ICP A / S Name area, the name of the ISP / ICP application server that has transmitted the specific event is described, and an IP address may be described instead of the name of the ISP / ICP application server. In addition, the name of the internal server that processes the event corresponding to the transaction code is described in the Server Name area, and the IP address of the internal server may be described instead of the name of the internal server. Also, in the Other Information area, additional information required for each transaction is described.

Next, an operation process of the SI server 164 will be described with reference to FIG. 12.

12 is a flowchart illustrating an operation of the SI server 164 of FIG. 2.

Referring to FIG. 12, the SI server 164 waits for receiving an event in step 1211 and proceeds to step 1213. In step 1213, when the event is received, the SI server 164 checks whether the received event is received from the application server 200. If the reception event is received from the application server 200, the SI server 164 proceeds to step 1215. In step 1215, the SI server 164 analyzes the event and proceeds to step 1217. In step 1217, the SI server 164 determines an internal server of the mobile communication system 160 to transmit the reception event according to the event analysis result and proceeds to step 1219. Here, the internal server for transmitting the received event is determined with reference to the message routing database 913.

In step 1219, the SI server 164 allocates a transaction code to the received event, maps the received event to the assigned transaction code, stores the received event in the transaction log database 911, and proceeds to step 1221. In step 1221, the SI server 164 transmits the reception event to the determined internal server, and returns to step 1211.

On the other hand, if the reception event is not received from the application server 200 as a result of the check in step 1213, that is, if received from the internal server of the mobile communication system 160, the SI server 164 proceeds to step 1223. do. In step 1223, since the event is received from the internal server, the SI server 164 detects the transaction code of the received event and proceeds to step 1225. In step 1225, the SI server 164 transmits the reception event to the application server 200 mapped to the detected transaction code by referring to the transaction log database 911 and proceeds to step 1227.

In step 1227, the SI server 164 deletes the information corresponding to the transaction code from the transaction log database 911 and proceeds to step 1229. In step 1229, the SI server 164 transmits a Transaction Billing Request message to the billing server 169 to bill the application 200 according to the completion of the event, and returns to step 1211.

Next, a message format transmitted and received in the communication network of FIG. 2 will be described with reference to FIGS. 13A and 13B.

13A and 13B schematically illustrate a message format transmitted and received in the communication network of FIG. 2.

The message format shown in FIG. 13A indicates a message format when a transaction code is explicitly described in a message, and the message format shown in FIG. 13B indicates when the transaction code is not explicitly described in a message. Indicates the message format. If the transaction code is not explicitly described in the message, the ISP / ICP A / S ID may be described in place of the transaction code.

13A and 13B, a message type area is an area indicating a type of a corresponding message. For example, the message type area may be represented as follows according to the message.

<Message type>

(1) Transaction-Bill-Token: 0x0001

(2) Transaction-Billing-Request: 0x0002

(3) Location-Info-Request: 0x0101

(4) Location-Info-Result: 0x0102

(5) Location-Tracking-Request: 0x0103

(6) Location-Report: 0x0104

(7) Device-Info-Request: 0x0201

(8) Device-Info-Result: 0x0202

(9) User-Profile-Request: 0x0301

(10) User-Profile-Result: 0x0302

(11) Paging-Request: 0x0401

(12) Paging-Response: 0x0402

(13) Service-QoS-Support: 0x0501

(14) Service-QoS-Assignment: 0x0502

In addition, different information is recorded for each type of a corresponding message in the message body area. For example, the message body may be represented as follows according to the message.

<Message body>

(1) Transaction-Bill-Token

{

Authorized Bill Token; [Reliability Information issued by ISP / ICP A / S]

}

(2) Transaction-Billing-Request

{

ISP / ICP A / S ID; [ISP / ICP A / S ID for future payment]

Billing-Information; [Transaction information to request]

}

(3) Location-Info-Request

{

User / Device ID; [Target user or device ID]

Accuracy; [Accuracy Requirements for Location Information]

}

(4) Location-Info-Result

{

Geo-Location-Information; [Location information of target user or device]

}

(5) Location-Tracking-Request

{

User / Device ID; [Target user or device ID]

Period; [Location information serving time requirement]

Interval; [Location requirements]

Accuracy; Geolocation Accuracy Requirements

}

(6) Location-Report

{

Geo-Location-Information; [Location information of target user or Diabis]

}

   (7) Device-Info-Request

{

User / Device ID; [Target user or device ID]

}

(8) Device-Info-Result

{

Device Type; [Target device type (eg PC, PDA, PMP, ...)]

O / S Type; [O / S type of target Diavis (eg Windows, Mac, ...)]

Display Resolution; [Display Resolution of Target Device]

Web Browser Type; [Supported Web Browser Types / Versions of Target Devices]

IP Info [IP information of the target device]

Other; [Other Additional Information]

}

(9) User-Profile-Request

{

User / Device ID; [Target user or device ID]

}

(10) User-Profile-Result

{

Sex; [Target user gender]

Home Address; [Target home address]

Office Address; [Target user's work address]

Habit; [Target User Hobbies]

Average Charging Rate; [Target average user fee]

Preferred Services; Target User Preferred Service

Other; [Other Additional Information]

}

(11) Paging-Request

{

User / Device ID; [Target user or device ID]

Paging-Information; [Additional Information to Send to Target User]

}

(12) Paging-Response

{

Paging-Response; [Reply from Target User / Device]

}

(13) Service-QoS-Support

{

User / Device ID; [Target user or device ID]

Service QoS Information; QoS Request Information for Service

}

(14) Service-QoS-Assignment

{

QoS Assignment Information; QoS information assigned for the service

              [Ex: TCP / UDP port number assigned]

              [Assigned baud rate]

              [Assigned DSCP code number]

}

On the other hand, when not using the transaction code as described above, the SI server 164 does not need to operate the transaction log database 911 separately. That is, the SI server 164 may operate in the same manner as in the case of using a transaction code by transmitting and receiving a message using an ISP / ICP A / S server instead of the transaction code. In this case, since the transaction log database 911 is not operated, the load of the SI server 164 is reduced.

Next, an internal structure of the charging server 169 will be described with reference to FIGS. 14A and 14B.

14A and 14B illustrate an internal structure of the charging server 169 of FIG.

The internal structure of the billing server 169 shown in FIG. 14A is an internal structure in consideration of not only the application server 200 but also the billing for the MS 170, and the billing server 169 shown in FIG. 14B. The internal structure of is an internal structure when only accounting for the application server 200 is considered.

Referring to FIG. 14A, the billing server 169 includes an application server billing database 1411, an MS billing database 1413, a controller 1415, an input line interface unit 1417, and an output line. An interface unit 1419.

The input line interface unit 1417 and the output line interface unit 1418 provide an internship with internal servers of the mobile communication system 160, eg, the SI server 164. In addition, the application server charging database 1411 stores charging information for the application server 200 that is performed under the control of the controller 1415. As described above, the present invention will be described based on an example of charging based on the ID of the application server 200. For example, the charging server 169 also charges in units of the application server 200 as an example. Explanation was made. However, since the mobile communication system 160 may collectively manage charges for all application servers in the mobile communication system 160, the mobile communication system 160 itself, not the application server 200, may be used. Of course, you can charge based. The MS charging database 1413 stores charging information for the MS 170 that is performed under the control of the controller 1415.

Referring to FIG. 14B, the charging server 169 includes an application server charging database 1411, a controller 1415, an input line interface unit 1417, and an output line interface unit 1419. As shown in FIG. 14B, the charging server 169 considering only the charging for the application server 200 does not include only the MS charging database 1413.

Next, an internal information structure of the application server charging database 1411 of FIGS. 14A and 14B will be described with reference to FIG. 15.

15 is a diagram illustrating an internal information structure of the application server charging database 1411 of FIGS. 14A and 14B.

Referring to FIG. 15, first, the application server billing database 1411 includes an application server ID area, a transaction type area, a date / time area, and a detail information area. It includes. The transaction type field describes the corresponding event, that is, the type of the corresponding transaction, and the date / time field describes the date and time at which charging was performed according to the corresponding event.

Next, an operation process of the charging server 169 will be described with reference to FIG. 16.

FIG. 16 is a flowchart illustrating an operation process of the charging server 169 of FIG. 2.

Referring to FIG. 16, the charging server 169 waits to receive an event in step 1611, and proceeds to step 1613. In step 1613, when the event is received, the charging server 169 checks whether the received event is an event for the application server 200. If the reception event is an event for the application server 200, the charging server 169 proceeds to step 1615. In step 1615, the charging server 169 analyzes the reception event, writes the ID of the application server 200 in the application server ID area of the application server charging database 1411, and proceeds to step 1617.

In step 1617, the charging server 169 writes the transaction type of the received event in the transaction type area of the application server charging database 1411, and proceeds to step 1619. In step 1619, the charging server 169 writes information on the date and time of the received event in the date / time area of the application server charging database 1411, and proceeds to step 1621. In step 1621, the charging server 169 writes detailed information of the received event in a detailed information area of the application server charging database 1411 and returns to step 1611.

If the reception event is not an event for the application server 200, that is, an event for the MS 170, the charging server 169 proceeds to step 1623. In step 1623, the charging server 169 writes the charging information for the MS 170 in the MS charging database 1413, and returns to step 1611.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

The present invention as described above has the advantage of enabling the service interface of the mobile communication system and the Internet service / content providing system. That is, the present invention enables the mobile communication system to use Internet service / content related information managed by the Internet service / content providing system, and the mobile communication system managed by the mobile communication system by the Internet service / content providing system. Make it possible to use the information. Therefore, there is an advantage of improving the service that can be provided in the mobile communication system and the Internet service / content providing system. In addition, the improvement of services that each of the mobile communication system and the Internet service / content providing system can provide through the service interface between the mobile communication system and the Internet service / content providing system may result in a change in the service type of the corresponding operators. It has the advantage that it can bring additional economic effect.

Claims (36)

In the method of performing an interface in a communication network, Receiving an event to be processed using information managed by the second system providing the second service from the first system providing the first service, Performing an interface between the first system and the second system such that the second system uses the information to perform an operation corresponding to the event; The first system is an application server of an Internet Service / Contents Provider (IS / CP), and the second system is a Universal Service Interface (USI) server of a mobile communication system. A USI server is provided between an operator of the mobile communication system and an Internet content provider of the Internet service / content providing system, and provides information stored in a server of the mobile communication system to the Internet content provider. If the event is an authentication request message, performing an interface to perform an operation corresponding to the event; The USI server performs authentication on the application server, and transmits an authentication response message including an authentication result to the application server, The authentication request message includes fields as shown in Table 11 below, and the authentication response message includes fields as shown in Table 12 below.

In Table 11, the data type (DataType) of the ISPname field, the Account field, and the Password field is a string, and ISPname represents the name of the application server that has requested authentication to the USI server, and Account represents the account of the subscriber. Password indicates subscriber's password.

In Table 12, the data type of the resultCode field is an integer, and the resultCode indicates an authentication result performed by the USI server. delete delete delete delete delete delete delete The method of claim 1, If the event is a location information request message, Performing an interface to perform an operation corresponding to the event; The USI server searching for location information of a subscriber to search for location information indicated by the location information request message, and transmitting a location information response message including the location information search result to the application server; The location information request message includes fields as shown in Table 13 below, and the location information response message includes fields as shown in Table 14 below.

In Table 13, the data type of the userIDtype field, the userID field, and the requestType field is a string, the data type of the ChargingFlag field is a number, and userIDtype represents the Internet Protocol address of the subscriber. userID represents the identifier of the subscriber, requestType represents the service classification, and ChargingFlag is a flag indicating the billing target.

In Table 14, the data type of the geographicInfo field is a string, and geographicInfo represents information about the region where the subscriber is located. The method of claim 1, If the event is a device information request message, Performing an interface to perform an operation corresponding to the event; The USI server searching for device information of a subscriber to search for device information indicated by the device information request message, and transmitting a device information response message including the device information search result to the application server; The device information request message includes fields as shown in Table 15 below, and the device information response message includes fields as shown in Table 16 below.

In Table 15, the userIDtype field, the userID field is a string, the data type of the ChargingFlag field is a number, the userIDtype represents the subscriber's Internet protocol address, the userID represents the subscriber's identifier, and the ChargingFlag Is a flag indicating the object of billing.

In Table 16, the data type of all fields included in the device information response message is a string, deviceType indicates the type of subscriber, deviceVendor indicates the manufacturer of the subscriber, deviceModel indicates the model information of the subscriber, and deviceOSVersion is DeviceTotalMemory represents the subscriber's total memory size, deviceFreeMemory represents the subscriber's currently available memory size, deviceResolution represents the subscriber's resolution, and MACAddress represents the subscriber's media access control address. Where IPAddress represents the subscriber's Internet Protocol address, phoneNumber represents the subscriber's telephone number, connectivitySupported represents the connectivity available to the subscriber, and currentConnectivity represents the subscriber's current Using indicate a possible connectivity, defaultWebBrowserType represents the default Web browser, type of subscriber, defaultWebBrowserVersion represents the default Web browser version of the subscribers. The method of claim 1, If the event is a Quality of Service (QoS) policy request message, Performing an interface to perform an operation corresponding to the event; The USI server searching for the QoS policy of the subscriber requesting the QoS policy indicated by the QoS policy request message, and transmitting a QoS policy response message including the QoS policy search result to the application server; The QoS policy request message includes fields as shown in Table 17 below, and the QoS policy response message includes fields as shown in Table 18 below.

In Table 17, the type of the Session ID field, the srcPort field, the destPort field, and the Charging Flag field is a number, the remaining fields are strings, and the Session ID is a session ID. The type indicates the identifier, the type of requestType indicates Reserved or Terminated, srcIPAddress indicates the Internet Protocol (IP) address of the application server providing the service, srcPort indicates the port of the application server providing the service, and destIPAddress indicates the subscriber. DestPort indicates the port of the subscriber, serviceType indicates the type of service provided, direction indicates the QoS support direction, and when the requestType type is Reservered, it indicates a message requesting to start the QoS service. In the case of Terminated, a message requesting to terminate the QoS service is displayed. Smell.

In Table 18, the data type of the ResultCode field is an integer, and ResultCode indicates whether a QoS policy for the QoS policy request message can be provided. The method of claim 1, If the event is a service alert request message, Performing an interface to perform an operation corresponding to the event; The USI server searching for whether paging for the subscriber requesting paging indicated by the service alert request message is possible, and transmitting a service alert response message including the paging search result to the application server; The service alert request message includes fields as shown in Table 19 below, and the service alert response message includes fields as shown in Table 20 below.

In Table 19, the data type of the userIDType field, the userID field, the calleeIDType field, the calleeID field, and the applicationType field is a string, and the data type of the ChargingFlag field is a number. Denotes an Internet Protocol (IP) address of a subscriber requesting paging, userID denotes an identifier of a subscriber requesting paging, calleeIDType denotes an IP address of a subscriber receiving paging, and calleeID denotes a paging received Indicates the subscriber's identifier, and applicationType indicates the type of messenger used.

In Table 20, the data type of the ResultCode field indicates an integer, and the ResultCode indicates whether paging for the service alert request message can be provided. An interface performing apparatus in a communication network, Receive an event to be processed using information managed by a second system that provides a second service from a first system that provides a first service, and the second system uses the information to correspond to the event. A service interface server for performing an interface between the first system and the second system to perform an operation; The first system is an application server of an Internet Service / Contents Provider (IS / CP), and the second system is a Universal Service Interface (USI) server of a mobile communication system. The USI server is located between the mobile communication system and the Internet content provider of the Internet service / content providing system, and provides information stored in the USI server of the mobile communication system to the Internet content provider. If the event is an authentication request message, the USI server performs authentication on the application server, and transmits an authentication response message including an authentication result to the application server. And the authentication request message includes fields as shown in Table 21 below, and the authentication response message includes fields as shown in Table 22 below.

In Table 21, the data type (DataType) of the ISPname field, the Account field, and the Password field is a string, and ISPname represents the name of the application server that has requested authentication to the USI server, and Account represents the subscriber's account. Password indicates subscriber's password.

In Table 22, the data type of the resultCode field is an integer, and the resultCode indicates an authentication result performed by the USI server. delete delete delete delete delete delete delete The method of claim 13, If the event is a location information request message, The USI server retrieves the location information of the subscriber to search for location information indicated by the location information request message, and transmits a location information response message including the location information search result to the application server. And the location information request message includes fields as shown in Table 23 below, and the location information response message includes fields as shown in Table 24 below.

In Table 23, a data type of a userIDtype field, a userID field, and a requestType field is a string, a data type of a ChargingFlag field is a number, and userIDtype represents an Internet Protocol address of the subscriber. userID represents the identifier of the subscriber, requestType represents the service classification, and ChargingFlag is a flag indicating the billing target.

In Table 24, the data type of the geographicInfo field is a string, and geographicInfo represents information on the region where the subscriber is located. The method of claim 13, If the event is a device information request message, The USI server retrieves the device information of the subscriber to search for device information indicated by the device information request message, and transmits a device information response message including the device information search result to the application server, Wherein the device information request message includes fields as shown in Table 25 below, and the device information response message includes fields as shown in Table 26 below.

In Table 25, the userIDtype field, the userID field is a string, the data type of the ChargingFlag field is a number, the userIDtype represents the Internet Protocol address of the subscriber, the userID represents the identifier of the subscriber, ChargingFlag Is a flag indicating the object of billing.

In Table 26, the data type of all fields included in the device information response message is a string, deviceType indicates the type of subscriber, deviceVendor indicates the manufacturer of the subscriber, deviceModel indicates the model information of the subscriber, and deviceOSVersion is DeviceTotalMemory represents the subscriber's total memory size, deviceFreeMemory represents the subscriber's currently available memory size, deviceResolution represents the subscriber's resolution, and MACAddress represents the subscriber's media access control address. Where IPAddress represents the subscriber's Internet Protocol address, phoneNumber represents the subscriber's telephone number, connectivitySupported represents the connectivity available to the subscriber, and currentConnectivity represents the subscriber's current Using indicate a possible connectivity, defaultWebBrowserType represents the default Web browser, type of subscriber, defaultWebBrowserVersion represents the default Web browser version of the subscribers. The method of claim 13, If the event is a Quality of Service (QoS) policy request message, The USI server retrieves a QoS policy of a subscriber requesting a QoS policy indicated by the QoS policy request message, and transmits a QoS policy response message including the result of the QoS policy search to the application server, And the QoS policy request message includes fields as shown in Table 27 below, and the QoS policy response message includes fields as shown in Table 28 below.

In Table 27, the type of the Session ID field, the srcPort field, the destPort field, and the Charging Flag field is a number, the remaining fields are strings, and the Session ID is a session ID. The type indicates the identifier, the type of requestType indicates Reserved or Terminated, srcIPAddress indicates the Internet Protocol (IP) address of the application server providing the service, srcPort indicates the port of the application server providing the service, and destIPAddress indicates the subscriber. DestPort indicates the port of the subscriber, serviceType indicates the type of service provided, direction indicates the QoS support direction, and when the requestType type is Reservered, it indicates a message requesting to start the QoS service. In the case of Terminated, a message requesting to terminate the QoS service is displayed. Smell.

In Table 28, the data type of the ResultCode field is an integer, and ResultCode indicates whether a QoS policy for the QoS policy request message can be provided. The method of claim 13, If the event is a service alert request message, The USI server retrieves whether paging is possible for the subscriber requesting paging indicated by the service alert request message, and transmits a service alert response message including the paging search result to the application server; And the service alert request message includes fields as shown in Table 29 below, and the service alert response message includes fields as shown in Table 30 below.

In Table 29, the data type of the userIDType field, the userID field, the calleeIDType field, the calleeID field, and the applicationType field is a string, and the data type of the ChargingFlag field is a number. Denotes an Internet Protocol (IP) address of a subscriber requesting paging, userID denotes an identifier of a subscriber requesting paging, calleeIDType denotes an IP address of a subscriber receiving paging, and calleeID denotes a paging received Indicates the subscriber's identifier, and applicationType indicates the type of messenger used.

In Table 30, the data type of the ResultCode field indicates an integer, and ResultCode indicates whether paging for the service alert request message can be provided. delete delete delete delete delete delete delete delete delete delete delete delete

Images