KR100972084B1 - Apparatus and method for charging in ims system - Google Patents

Abstract

The present invention relates to an apparatus and a method for charging in an IMS system, and to provide an IMS charging apparatus having a flexible structure capable of supporting rapid introduction and exit of various services. To this end, the present invention comprises the steps of receiving a charging request message from the charging node, detecting the media type information from the SDP media information of the received charging request message, and detecting port information from the SDP media information of the received charging request message. And generating the billing processing data using the detected media type information and the detected port information, and calculating the billing data using the billing processing data.

IP Multimedia Subsystem (IMS), Billing, Charging Collection Function (CCF), DIAMETER

Description

Charging apparatus and method in IMS system {APPARATUS AND METHOD FOR CHARGING IN IMS SYSTEM}

The present invention relates to an apparatus and method for charging in an IP Multimedia Subsystem (IMS) system, and more particularly, to an apparatus and method for calculating usage-based charging data by processing various charging events in an IMS-based service providing structure.

IMS (IP Multimedia Subsystem), which was introduced to provide all-IP based services, is a service platform that can create a rich communication environment and facilitate the integration of wired and wireless networks. As a service platform, IMS provides integrated control and lowers operating and investment costs with the flexibility and simplicity of a single infrastructure. In a market environment where services are frequently introduced and exited, the ability to charge for new services flexibly and efficiently is important, and IMS offers the possibility of securing the same billing system for all services. .

In order to meet these requirements, the 3rd Generation Partnership Project (3GPP), a standardization organization, presents an infrastructure of charging devices that can be universally applied to various services. For IMS, a common logical charging structure is defined instead of the charging function for each individual service. This logical charging structure is defined from one logical charging function that is derived to enable the different characteristics required for all charging related parts in the network. Under this structure, specifications relating to specific technologies and services define the detailed specifications of the charging process necessary for charging for the use of individual technologies or services. These subdivisions can be divided into bearer level charging (access charging) and subsystem accounting (IMS charging) and service level charging (service / content charging).

Basically, IMS is a service platform designed to control and support sessions established between a pair of peer nodes. The IMS is only responsible for signaling and control of the session and is not involved in the actual flow of data or media flows within the session. Such media flows or data transfers often do not actually go through the IMS platform. IMS basically uses Session Initiation Protocol (SIP) for session control and signaling, and actual traffic is delivered through Real-time Transport Protocol (RTP).

The charging function in this IMS is dualized by offline charging and online charging. The 3GPP standard defines two charging models for the charging process: offline charging and online charging. Offline billing refers to a billing process that receives the details of a SIP-based billing trigger event, generates a charging data record (CDR) so that the user can be billed, and delivers it to a customer management system. In the offline charging process, after a resource related event occurs in the network domain, the resource usage history is transmitted to the billing system (Billing System or Billing Domain) through a series of logical charging functions. Therefore, there is no direct billing linkage between the billing process and the service being provided. On the other hand, in the online billing, for the balance inquiry or credit inquiry, real-time linkage between the billing process and the service being provided. Therefore, in addition to the identification of chargeable events, authorization checks for resource use are required before actual resource use.

Offline charging defined by the 3GPP standard (3GPP Release 6) includes three logical charges: Charging Trigger Function (CTF), Charging Data Function (CDF), and Charging Gateway Function (CGF). It consists of functions. The charging trigger function (CTF) is included in the related resource or service providing element and generates a charging event when an event that requires charging occurs. A billing event is a billing record that includes billing information and characteristics about the event. The charging trigger function (CTF) delivers the charging event to the charging data function through an RF (Radio Frequency) interface using an accounting application of the DIAMETER BASE protocol. The billing data function (CDF) and billing gateway function (CGF) process the collected billing events into a single billable billing data and deliver it to the billing system. The 3GPP standard defines a set of billing interworking interfaces and the function of each node as above. However, the configuration and algorithm of each node to actually charge is not defined and may be configured differently according to the system designer.

Accordingly, an object of the present invention is to provide an IMS (IP Multimedia Subsystem) billing device having a flexible structure capable of supporting rapid introduction and exit of various services.

In addition, the present invention provides a structure and algorithm for implementing a charging collection function (CCF: Charging Collection Function) of the IMS system, including information on the actual usage of the media using the charging-related event information generated in the IMS charging node Another object is to provide an apparatus and a method for generating billing data.

The objects of the present invention are not limited to the above-mentioned objects, and other objects and advantages of the present invention which are not mentioned above can be understood by the following description, and will be more clearly understood by the embodiments of the present invention. It will also be readily apparent that the objects and advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

In order to achieve the above object, the present invention provides a method of charging in an IP multimedia subsystem (IMS) system, the method comprising: receiving a charging request message from a charging node, and receiving a SDP (Session) of the received charging request message; Description Protocol) detecting media type information from media information, detecting port information from SDP media information of the received charging request message, and charging using the detected media type information and the detected port information. And generating billing data by using the billing data.

In another aspect of the present invention, there is provided a billing apparatus in an IMS system, comprising: a message receiver for receiving a billing request message from a billing node; a media type detector for detecting media type information from SDP media information of the received billing request message; A port detector for detecting port information from the SDP media information of the charged accounting request message, a billing processing data generating unit for generating billing processing data using the media type information and the media port information, and the billing processing data; Another feature is to include a billing data calculation unit for calculating billing data by using.

According to the present invention as described above, it is possible to provide an IP Multimedia Subsystem (IMS) charging device having a flexible structure suitable for rapid introduction and exit of various services. In particular, by providing a structure and algorithm for implementing the Charging Collection Function (CCF) of the IMS system, the billing data including information on the actual usage of the media using the billing-related event information generated in the IMS billing node Can be generated.

The above objects, features, and advantages will be described in detail with reference to the accompanying drawings, whereby those skilled in the art to which the present invention pertains may easily implement the technical idea of the present invention. In describing the present invention, when it is determined that the detailed description of the known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description will be omitted. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a configuration of the charging function of the IMS system according to the present invention.

All IMS functional entities (CSCF, AS, MRFC, BGCF, MGCF, etc.) perform the IMS charging function through the Charging Trigger Function (CTF). The CTF monitors signaling messages related to generation of predefined Session Initiation Protocol (SIP) or Integrated Services Digital Network User Part (ISP) messages to trigger the generation of accounting information.

CTF is an entity that integrates charging related resources or elements of service. The CTF generates charging information when an event that requires charging occurs. Since the IMS nodes are not involved in the actual media flow, the CTF does not generate information about media usage, but rather generates a data record containing a set of billing information that records the characteristics of the chargeable event. This set of billing information is passed to the Charging Data Function (CDF) through the accounting application of the DIAMETER BASE protocol, ie the RF interface.

The billing information is delivered through a DIAMETER message in the form of an attribute-value pair (AVP). DIAMETER messages for offline charging 110 of IMS are ACR (Accounting Request) and ACA (Accounting Answer). There are ACR related to IMS session such as Start, Interim, Stop. An ACA is used as a response message for a successful session, and an ACR message of an event type is used for a response related to a failed SIP session and a message related to a session. The definition of a signaling message (SIP in IMS) for transmitting ACR may vary depending on the network configuration and business model of the operator. In general, ACR [START] for SIP 200 OK messages for SIP INVITE, ACR [INTERIM] for SIP 200 OK messages for SIP INVITE, UPDATE, RE-INVITE, etc. and SIP 200 OK messages for SIP BYE. In this case, send ACR [STOP].

Tables 1 to 3 are the main factors for information delivery in the billing message, defined between the CTF and the CDF in the IMS-based billing structure to which the present invention is applied.

AVP  persons Explanation Session-Id Identifier to identify accounting session Origin-Host Host name of the Service-Node that generated the ACR message Origin-Realm Service-Node's Domain (Realm) Destination-Realm Domain to which ACR messages are routed (Realm) Accounting-Record-Type The type of billing of the message (Start, Interim, Stop, Event) Accounting-Record-Number Display billing data sequence number within the same session Acct-Application-Id Charge Separator by Diameter Application User-Name ISIM's private user identity, IMS service access ID,
(For AS: AS server name or provided service name) Acct-interim-interval Interim-Interval Value Origin-State-Id Increment one by one, increasing at any time during the past state of the Diameter entity, for example when it is restarted with loss, such as when it is rebooted. Event-Timestamp When the reported event occurred Service - Information 3GPP Service Information Elements

AVP Name Sub AVP Name Description Service - Information Subscription-ID End User Subscriber ID IMS-Information AVP carries additional IMS Service Specific Information Element

AVP Name Sub AVP Name Description Subscription-ID End User Subscriber ID Event-Type SIP message information that generated the billing message SIP-Method SIP Method (e.g. INVITE, SUBSCRIBE, etc.) Event Contents of SIP Event Header Fields Expires Contents of the SIP Expires Header Field Role-Of-Node Incoming Call, Incoming Call, Proxy, B2BUA, etc. Node-Functionality Functional separator of Node (AS, CSCF, etc.) User-Session-Id Session identifier, SIP call ID if SIP session * Calling-Party-Address Public User (or Service) ID of originating terminal
(SIP URI or Tel URI) Called-Party-Address Public User (or Service) ID of the called terminal
(SIP URI or Tel URI) * Called-Asserted-Identity Address of the final asserted called party (public user-ID: SIP-URI or TEL-URI)

Alternate-Charged-Party-Address (64) 3rd party billing ID (from AS)
Identity of real user of AS when Address is virtual ID between CSCF-AS when establishing SIP Session through CSCF Time-stamps Initial SIP Request and Response Time Information for Request SIP-Request-TimeStamp First SIP Request Time
The time the service was requested SIP-Response-TimeStamp Response time for the first SIP request
Time to provide response to service request * Application-Server-Information Information of AS via ISC Interface Application-Server SIP URL (or service name) of the specified AS for the duration of the session. Application-Provided-Called-Party-Address Called Party Number determined by AS (SIP URI, E164) * Inter-Operator-Identifier Incoming and outgoing network identification information Origination-IOI IOI for the originating network
(Network domain where SIP was first created) Terminating-IOI Incoming side network for IOI
(SIP is the network domain where the message finally arrived.) IMS-Charging-Identifier IMS Charging ID (ICID) * SDP-Session-Description Line describing session in SDP content (eg o =-1073055600 1073055600 IN IP6 1080 :: 8: 800: 200C: 417A)
o-line (Origin) is required among the line elements of v, o, k, c, b, t, etc. * SDP-Media-Component Information used for media during an SDP session SDP-Media-Name "M =" line in the SDP
m = <media><port><proto><fmt> ...
<media>: media type audio, video, text, application, message
<port>: port or port / <number of ports>
<proto> protocol udp, RTP / AVP, RTP / SAVP
(eg m = audio 49170/2 RTP / AVP 31) Media-initiator-flag Where media stream is created through SIP message (0: called party, 1: calling party, 2: unknown) Authorized-QoS
All information of IP Flow (s) authorized by P-CSCF contained in this Media-Component (Maximum Bandwidth, QoS Class, ...)
* P-CSCF only 3GPP-Charging-Id Connection session ID created by connection control node Access-Network-Charging-Identifier-Value (20) Served-Party-IP-Address IP address of terminal in charge of node * Service-Specific-Info Used by the AS to inform you about specific services Service-Specific-Data Service content for the type Service-Specific-Type Type of Service-Specific-Data Cause-Code Reason code for termination (0: normal end of session, 1: Unknown Error, ~) Access-Network-Information P-Access-Network-Information QoS-timeout KT vender-specific-AVP only for P-CSCF (vender-ID = 14008)
P-CSCF extracts from RAR message sent to P-CSCF after QM detects setup failure of preset QoS flow.

The CDF is a logical functional entity that uses the received billing information to generate a charging data record having a standardized content and format. The charging device according to the present invention is implemented as a charging collection function (CCF: 100), CCF 100 is a function that integrates the CDF and the charging gateway function (CGF: Charging Gateway Function).

2 is a simplified network diagram of an IMS system according to the present invention.

As shown, call session control functions (CSCFs) 220, 230, 250, and 260, which are the most basic billing nodes associated with service usage of the IMS system, and application servers (ASs) 240 Call setup is done via. Most services provided purely in the IMS domain are session set up only through P-CSCF (Proxy-CSCF) 220 and 260 and S-CSCF (Serving-CSCF) 230 and 250. On the other hand, the service to which additional services or other additional functions are to be additionally applied, session establishment is performed through the AS 240.

When receiving the SIP message (SIP INVITE, RE-INVITE, BYE, 200 OK, etc.) transmitted from the terminal A (210), each billing node, if it is determined that the relevant billing event should be triggered, the billing information according to the corresponding event Create Since the SIP message passes through all nodes on the connection establishment path related to call establishment, all nodes on the path generate charging information for the message. Thus, the P-CSCF 220, 260, S-CSCF 230, 250, AS 240, I-CSCF (Interrogating-CSCF), etc. generate charging information of the same attribute for the same SIP message. The generated billing information is transferred to the CCF 200 along with additional information such as role and function of each node.

In this structure, the CCF 200 may predict or determine whether billing information is generated or should be generated at a node other than the originating P-CSCF 220 and the originating S-CSCF 230 for a specific IMS service. Can't. Therefore, since the charging information received by the CCF 200 depends on the type of service or the delivery path, a separate process for preventing duplication or omission of the charging information is required.

3 is a block diagram of the charging device 300 in the IMS system according to the present invention. As shown in FIG. 3, the billing apparatus 300 includes a message receiver 310, a billing data generator 330, a billing data calculator 340, and an IP billing data generator 350. The charging device 300 according to the present invention includes a CCF defined in the 3GPP standard.

The message receiver 310 receives the charging request message from the charging node. The billing request message does not include information on media usage, but includes information on the characteristics of the event to be charged. The message receiving unit 310 transmits a charging request message to the charging processing data generating unit 330. Here, the charging node may be a CTF such as an AS or CSCF, and the charging request message may be an ACR message by the DIAMETER BASE protocol.

The billing processing data generator 330 generates billing processing data from the received billing request message. The billing processing data generator 330 may include a filtering unit 320 to prevent duplicate billing. Since a plurality of billing request messages for billing information of the same attribute may be received from a plurality of billing nodes, the filtering unit 320 filters out duplicate messages. The filtering unit 320 filters the charging request message based on the function and role of the charging node. Information about the function and role of the charging node may be included in the charging request message sent by the charging node.

The billing processing data generating unit 330 generates billing processing data using SDP (Session Description Protocol) media information of the received billing request message. The billing processing data generator 330 may include a media type detector 332 or a media port detector 334. The SDP media information is information used for media during an SDP session and includes information on a media type, a port, a protocol, and the like. The media type detector 332 detects information on the media type from the SDP media information, and the media port detector 334 detects information on the media port from the SDP media information. The billing processing data generating unit 330 generates session information for each media or accounting information for each media by using information on a media type and a media port. The billing processing data includes one or more of session information for each media or accounting information for each media. The billing processing data generator 330 transmits the billing data generated in this way to the billing data calculator 340.

The billing data calculator 340 calculates billing data using the received billing data. The billing data is data that can be used directly for billing and is usage information on the media used by the actual user. The billing data calculator 340 may include a media searcher 342 that searches for media whose session has ended in order to calculate billing data. The charging data calculator 340 may transmit the calculated charging data to the IP charging data generator 350.

The IP charging data generator 350 generates IP charging data using the received charging data. IP billing data is used as a basis for billing users in billing systems.

4 is a flowchart of a charging method in an IMS system according to the present invention. The charging method according to the present invention will be described with reference to FIG. 3.

First, the message receiving unit 310 of the charging device 300 receives the charging request message from the charging node (410). The billing information included in the billing request message is not used for direct billing because it is not information on the usage of the media. The filtering unit 320 filters the received charging request message (420). Duplicate charging or missing charging does not occur because duplicate charging request messages and erroneous charging request messages for the same charging information are excluded in the filtering step 420.

The billing apparatus 300 generates billing processing data using the SDP media information of the billing request message that is not excluded (430). The billing device 300 calculates billing data, which is usage information about the media, using the generated billing data. The charging device 300 may generate 450 the IP charging data using the calculated charging data. IP billing data is used as a basis for billing users in billing systems.

5 is a detailed flowchart of the data generation step 430 for billing processing shown in FIG.

The billing processing data generating unit 330 detects the media type information and the media port information from the SDP media information of the received billing request message (510, 520), and generates (530) the billing processing data using the same.

The received SDP media information includes the type and port information of the media. The billing processing data generation unit 330 may know which media is used from the media type information, and may know the start and end of the session from the media port information. Therefore, through this, the billing processing data generation unit 330 may configure session information for each media. On the other hand, since the received billing request message includes accounting information of the billing request message, the billing processing data generation unit 330 configures accounting information for each media from accounting information, media type information, and media port information of the billing request message. can do. As described above, the billing processing data generation unit 330 generates billing processing data (530). The billing processing data is configured to include one or more of session information for each media or accounting information for each media.

FIG. 6 is a detailed flowchart of the step 440 of calculating charging data shown in FIG. 4.

First, the billing data calculator 340 searches for a media whose session is terminated by using the billing data generated by the billing data generator 330. When the media for which the session is terminated is searched 610, the billing data calculator 340 calculates billing data by collecting all information on the corresponding media session from billing processing data. The billing data calculator 340 may refer to session information for each media or accounting information for each media of billing processing data. The billing data calculator 340 may detect the start and end time of use of each media from the session information for each media, and may detect the start, change and end time of each media session from the media accounting information. The billing data calculator 340 calculates billing data using the media usage and session information as described above (440).

7 is a flowchart illustrating a step 420 of filtering a charge request message according to an embodiment of the present invention. The charging request message filtering step 420 according to an embodiment of the present invention will be described with reference to FIGS. 2 and 3.

In order to solve the above-mentioned problem of charging duplicated, the charging request message filtering step 420 according to an embodiment of the present invention applies the filtering rule for each service to use the charging information generated from a certain charging node to perform billing processing data. Decide if you want to create it. CSCFs 220, 230, 250, and 260 generate charging information for the triggered call, and AS 240 actually processes the call and generates charging information for it. The filtering step 420 determines which billing node of the CSCF 220, 230, 250, 260 or AS 240 to use billing information.

In this embodiment, the processing procedure for the ACR message, which is the charging request message, is as follows.

First, the CCF 300 parses 710 the received ACR message. If parsing fails, the CCF 300 discards the ACR message without further processing (730) according to the cause of the error, or sets the error cause value in the ResultCode AVP of the ACA message (778, 779) and sends the ACA message to the PEER (780). )do. The CCF 300 checks the filtering condition 740 to exclude the ACR message corresponding to the filtering condition from the message processing. Since the CCF 300 does not correspond to the filtering condition, the CCF 300 extracts SDP media information from the ACR message to be charged and stores the data in the database (760). The ACR message subject to billing processing is used to generate data for billing processing.

The filtering conditions are as follows. First, as a condition for excluding all data except the data transmitted from the originating S-CSCF 230 and the AS 240 from being processed, the Role-Of-Node is' 0 (= originating) 'and the Node-Functionality is' This is not the case with 0 (= S-CSCF) 'or' 6 (= AS) '. Second, as a condition not to use the charging information of S-CSCF in order to use AS charging information for charging, Node-Functionality is '0 (= S-CSCF)' and there is Application-Server information. When a value is registered as a filtering condition. Third, as a condition to exclude the case where accounting information is INTERIM and STOP for simple refresh among billing request messages, Node-Functionality is '0 (= S-CSCF)' and SDP media information (SDP-Media -Component) does not exist. Fourth, it does not include User-Name.

The IMS exchanges media information related to service usage through SDP of SIP. When the charging event related to the SIP message occurs, the media information of the SDP is carried by the CTF in the SDP-Media Component parameter and transferred to the CCF. At this time, since the transmitted media information is not related to usage information but media related port information, the CCF should extract media usage for billing by recording a change in media port information.

In an embodiment of the present invention, the CCF separates the received media information for each media in order to extract the usage amount of each media to generate data for billing processing. The billing processing data may include session information for each media or accounting information for each media.

As a data structure for this, three database tables T_Service, T_Service_Sub, and T_Service_Data may be configured. The T_Service table is a table for storing received ACR messages and stores accounting information of ACR messages such as Accounting Start, Interim, and Stop. The T_Service_Sub table is a table for storing session information for each media, and stores session state for each media type. The T_Service_Data table is a table for storing accounting information for each media. The T_Service_Data table stores accounting information for each media type subdivided from accounting information for an ACR message.

Table 4 is a structure of a T_Service table according to an embodiment of the present invention.

turn Field name type size Explanation One icid VARCHAR 64 IMS-Charging-Identifier AVP 2 session_id VARCHAR 64 Session-Id AVP 3 login_id VARCHAR 64 User-Name AVP 4 acct_record_number NUMERIC 10 Accounting-Record-Number AVP 5 origin_host VARCHAR 64 Origin-Host AVP 6 session_seq NUMERIC 10 One 7 acct_record_type NUMERIC 4 Accounting-Record-Type AVP 8 event_timestamp NUMERIC 10 Event-Timestamp AVP

9 conv_timestamp CHAR 14 Event-Timestamp AVP 10 role_of_node NUMERIC 5 Role-Of-Node AVP 11 user_session_id VARCHAR 60 User-Session-Id AVP 12 calling_party_addr_0 VARCHAR 64 Calling-Party-Address AVP 13 calling_party_addr_1 VARCHAR 64 Calling-Party-Address AVP 14 called_party_addr VARCHAR 64 Called-Party_Address AVP 15 alter_charged_party_addr VARCHAR 64 Alternate-Charged-Party-Address AVP 16 request_timestamp NUMERIC 10 SIP-Request-TimeStamp AVP 17 conv_request_timestamp CHAR 14 SIP-Request-TimeStamp AVP 18 response_timestamp NUMERIC 10 SIP-Response-TimeStamp AVP 19 conv_response_timestamp CHAR 14 SIP-Response-TimeStamp AVP 20 application_server VARCHAR 60 Application-Server AVP 21 application_addr VARCHAR 64 Application-Provided-Called-Party-Address AVP 22 origination_ioi VARCHAR 60 Origination-IOI AVP 23 terminating_ioi VARCHAR 60 Terminating-IOI AVP 24 ip_address CHAR 15 SDP-Session-Description AVP 25 sdp_sess_id NUMERIC 20 SDP-Session-Description AVP 26 ggsn_addr CHAR 15 GGSN-Address AVP 27 served_party_ip_addr CHAR 15 Served-Party-IP-Address AVP 28 incoming_id VARCHAR 60 Incoming-Trunk-Group-ID AVP 29 outgoing_id VARCHAR 60 Outgoing-Trunk-Group-ID AVP 30 bearer_service VARCHAR 60 Bearer-Service AVP 31 service_id VARCHAR 60 Service-Id AVP 32 service_specific_data_1 VARCHAR 20 Service-Specific-Data AVP 33 service_specific_data_2 VARCHAR 4 Service-Specific-Data AVP 34 service_specific_data_3 VARCHAR 4 Service-Specific-Data AVP 35 service_specific_data_4 VARCHAR 4 Service-Specific-Data AVP 36 service_specific_data_5 VARCHAR 4 Service-Specific-Data AVP 37 service_specific_data_10 VARCHAR 4 Service-Specific-Data AVP 38 service_specific_data_11 VARCHAR 4 Service-Specific-Data AVP 39 service_specific_data_12 VARCHAR 4 Service-Specific-Data AVP 40 service_specific_data_13 VARCHAR 4 Service-Specific-Data AVP 41 service_specific_data_14 VARCHAR 4 Service-Specific-Data AVP 42 service_specific_data_15 VARCHAR 4 Service-Specific-Data AVP 43 service_specific_data_20 VARCHAR 60 Service-Specific-Data AVP 44 service_specific_data_21 VARCHAR 60 Service-Specific-Data AVP 45 service_specific_data_22 VARCHAR 60 Service-Specific-Data AVP 46 service_specific_data_23 VARCHAR 60 Service-Specific-Data AVP 47 cause_code NUMERIC 5 Cause-Code AVP 48 create_date CHAR 14 Record creation time

Table 5 shows a structure of a T_Service_Sub table according to an embodiment of the present invention.

turn Field name type size Explanation One icid VARCHAR 64 IMS-Charging-Identifier AVP 2 session_id VARCHAR 64 Session-Id AVP 3 login_id VARCHAR 64 User-Name AVP 4 acct_sub_session_id NUMERIC 20 SDP-Session-Description AVP 5 session_seq NUMERIC 10 6 node_functionality NUMERIC 2 Node-Functionality AVP 7 response_timestamp NUMERIC 10 SIP-Response-TimeStamp AVP 8 conv_response_timestamp CHAR 14 9 status CHAR 2 Session collection state (AS, AE, PS, etc.) 10 create_date CHAR 14 Generation time 11 update_date CHAR 14 Last change time 12 data_count NUMERIC 10 The number of data contained by this subsession
13 expire_time NUMERIC 10 The time at which the maritime subsession expires

14 term_code CHAR One 0: normal end, 1: timeout 15 host_id CHAR 4 Host id of the host on which the IMSIF process is running 16 acct_group NUMERIC 10 0: The entire media for ICID is Unknown
1: Some media in ICID is unknown
2: no unknown media in ICID 19 process_date CHAR 14  Final processing time

Table 6 shows a structure of a T_Service_Data table according to an embodiment of the present invention.

turn Field name type Length Explanation One icid VARCHAR 64 IMS-Charging-Identifier AVP 2 session_id VARCHAR 64 Session-Id AVP 3 login_id VARCHAR 64 User-Name AVP 4 acct_sub_session_id NUMERIC 20 SDP-Session-Description AVP 5 session_seq NUMERIC 10 6 acct_record_number NUMERIC 10 Accounting-Record-Number AVP 7 acct_record_type NUMERIC 4 Accounting-Record-Type AVP 8 real_record_type NUMERIC 4 9 media_type NUMERIC 2 SDP-Media-Name AVP 10 media_initiator_flag NUMERIC One Media-Initiator-Flag AVP 11 authorized_qos VARCHAR 20 Authorized-QoS AVP 12 bandwidth NUMERIC 10 Authorized-QoS AVP 13 create_date CHAR 14 Corresponding record creation time

8 is a flowchart illustrating a step of generating data for billing processing according to an embodiment of the present invention.

First, before storing values in the T_SERVICE, T_SERVICE_SUB, and T_SERVICE_DATA tables, the values are stored in the buffer allocated to each table using the AVP of the received ACR message (810). Next, in operation 820, an Acct-Record-Type indicating the accounting information of the ACR message among the AVPs of the ACR message is determined.

First, when the Acct-Record-Type is START, since the session is newly started, the corresponding information is inserted into T_SERVICE_DATA, T_SERVICE_SUB, and T_SERVICE (830, 840, 850). Second, if the Acct-Record-Type is INTERIM, there is a media session with a change among the included media sessions. Therefore, it is determined whether there is data having the same session ID (sessId) with reference to T_SERVICE (822). If the sessId is not the same and changed, the media is terminated (880). If the sessId is the same, a value is immediately stored in each table (830, 840, 850). Thirdly, if the Acct-Record-Type is STOP, since all media sessions are terminated, after the media is terminated (890), the value is stored in the T_SERVICE table (850).

9 is a configuration diagram of a database for explaining charging processing data according to an embodiment of the present invention. FIG. 9 shows data actually stored in a database table introduced to store data for billing processing described in conjunction with FIG. 8.

In each table, RecType represents accounting information, meaning 2 for ACR START, 3 for ACR INTERIM, and 4 for ACR STOP. In each table, media type represents a media type, where A is audio, V is video, and D is data. In each table, a session state indicates a start / end state of a media session, where an AS means a session started and an AE means a session terminated.

When ACR START message for a specific ICID (IMS Charging ID) is received (901, 902), the relevant information related to ACR is inserted into T_SERVICE and session information for each media is based on the port information included in SDP-Media-Component. Generate 901 and 902. At this time, since each media session is newly started, the session state for each media in the T_SERVICE_SUB table is all started (AS). Then, accounting information for each media is generated and inserted into the T_SERVICE_DATA table. Since all the media have been newly started, RecType of the T_SERVICE_DATA table representing the accounting information for each media is generated as 2 (901, 902).

When the first ACR INTERIM message for a specific ICID is received (903, 904, 905), the relevant information related to ACR is inserted into the T_SERVICE table, and the session information for each media is based on the port information included in the SDP-Media-Component. Modify or create Since the ACR INTERIM message is received when there is a change of session, the media session terminated due to the change is terminated, the retained media session modifies the data, and the new media session generates the data. As shown in FIG. 9, since the port of the audio (A) media of the ACR message has received 0, the port is interpreted to be terminated, and the state of the media session is changed to end (AE) in the T_SERVICE_SUB table (903). do. The session state for the retained video (V) media port and the newly created data (D) media port is maintained at start (AS) (904, 905). Accounting information is generated for each media and stored in RecType of T_SERVICE_DATA. Generates accounting STOP (RecType 4) data (903) for audio (A) where the media session is terminated, and accounting INTERIM (RecType 3) data (904) for video (V) that is a change or maintenance for an existing session (90). Accounting START (RecType 2) data 905 is generated and inserted into the data D.

When another ACR INTERIM message including only the video (V) port in the SDP media information is received (906, 907, 908, and 909), it is determined whether there is a session identical to the previously existing session ID (sessId). As shown in FIG. 9, since the sessId has been changed from 123 to 124, the media session against sessID 123 is terminated (906, 907, 908), and the session state is changed to (AE) (907, 908). . At this time, in the T_SERVICE_DATA table, accounting (RecType 4) data is inserted (907, 908) into the video (A) and the data (D) in which the media port information existing in the previous message disappears, and the video (V) in which the port information is maintained. ), The accounting INTERIM (RecType 3) data is inserted (909).

When an ACR STOP message is received (910, 911, 912, 913) for a specific ICID, all ongoing media sessions belonging to the corresponding ICID are terminated. As shown in FIG. 9, since the only session in progress is the video (V) port, the session state of the video (V) port is changed to end (AE) (913), and an accounting STOP (RecType 4) for the media session is performed. ) Data is generated and inserted into the T_SERVICE_DATA table (913).

In the above-described method, an embodiment of the present invention utilizes an open / closed state of a port delivered as port information included in an SDP-Media-Component of a SIP message. Generate information.

10 is a configuration diagram of a charging device according to an embodiment of the present invention.

The charging device having the structure shown in FIG. 10 implements the CCF 1000 function integrating the CDF and CGF of the 3GPP standard. The CCF 1000 is composed of five main processes, five system monitoring / control processes, and one operation management process.

DNIF (DIAMETER NETWORK Interface) 1031 performs a DIAMETER BASE engine function. The DNIF 1030 performs a capability negotiation process for establishing a DIAMETER PEER with the CTFs CSCF 1010 and the AS 1020. The DNIF 1030 establishes a connection to the corresponding PEER when the capability negotiation is successful, and transmits and receives a DIAMETER BASE message with the CTF when the connection setting is completed. The DNIF 1030 transfers the ACR message among the received messages to the IMSIF 1031, and receives the ACA from the IMSIF 1032 to the CTF for billing processing. In addition, the DNIF 1030 periodically checks the shared memory in which the PEER information is stored and maintains state information on the PEER.

The IMSIF 1032 processes the DIAMETER ACR message to generate data for billing processing. The IMSIF 1032 receives the ACR message from the DNIF 1031, checks whether the required AVP is missing, and rejects the appropriate ACA message. The IMSIF 1032 analyzes SDP media information in the ACR message to generate and manage billing data for calculating billing data.

IMS Process Charging Data Record (IPCDR) 1033 is a billing processing process that retrieves terminated media sessions to produce billing data. IRC Recovery Charging Data Record (IRCDR) 1034 is a billing recovery process that recovers or processes exception-generated data that is not completed due to a process or database failure during billing data processing. IMEDIF (IP Mediation Interface) 1035 is a process of retrieving billing data calculated by IPCDR 1033 and generating IP billing data (IPDR: IP Detail Record).

The SVCM 1036 is a service management process that processes system commands provided by the management and operation management functions for timers in the system. The SAMD (System Administration Monitoring Daemon) 1037 is a system monitoring process and collects system resource states such as system state, central processing unit (CPU) load, and memory / hard disk occupancy for an application process. The ERCD (Execute Report Collect Daemon) 1038 collects billing processing statistics, interface status information, database status information, etc. of the CCF 1000, and collects the collected information in an operation and maintenance processor (OPM) operator interface 1050 [3]. -11]. The IXPC 1039 is responsible for communication between each process operating inside the CCF 1000 and distributes messages between the processes. GUICOMM 1040 provides an interface for charging database access. The OMP operator interface 1050 is an operation management function, performs detailed functions for providing overall operation management and statistical functions of the CCF 1000, and provides an interface between the operator and the system.

FIG. 11 is a detailed block diagram of the charging data calculator 1033 according to an embodiment of the present invention shown in FIG. 10. The operation of the charging data calculator 340 according to an embodiment of the present invention will be described with reference to FIGS. 3 and 10.

In this embodiment, the IPCDR 1033, which is the billing data calculator 340, queries the T_SERVICE_SUB 1111 table to continuously search for a terminated session (session whose session status is AE). When the terminated session is found in the T_SERVICE_SUB 1111, the IPCDR 1033 processes the information in the T_SERVICE 1113, T_SEVICE_DATA 1112, and T_SERVICE_SUB 1111 tables equal to the ICID of the information to calculate the billing data.

IPCDR 1033 updates the HOST_ID of the corresponding information of both HOSTs to one side (SO01 or SO02) in consideration of the creation time and node functionality among both HOSTs having the same ICID before processing. (1120). This is to prevent possible database conflicts caused by the existence of the same session information on both HOSTs throughout the PEER node.

If two or more sessions exist in one ICID, IPCDR 1033 processes only one session information. The IPCDR 1033 inserts the processing result into the T_SERVICE_RSLT 1114, and deletes the charging information used in the processing from the T_SERVICE 1113, T_SEVICE_DATA 1112, and T_SERVICE_SUB 1111 tables (DELETE). 1130). If a failure occurs when performing a database query, the IPCDR 1033 stores the information in a specific directory for recovery from the IRCDR 1034.

12 is a detailed block diagram of the IP charging data generator 350 according to an embodiment of the present invention shown in FIG. The operation of the IP charging data generator 350 according to an embodiment of the present invention will be described with reference to FIGS. 3 and 10.

In this embodiment, the IMEDIF 1035, which is the IP billing data generator 350, is a billing transmission process for generating an IPDR that the billing system can use as basic data for billing the user. IMEDIF 1035 retrieves the IPDR data generated by the billing process from the database and generates an IPDR. In addition, the IMEDIF 1035 assigns a serial number to each IPDR data to determine a transmission omission, and stores necessary information such as a serial number and file information assigned in preparation for restarting the process in an MMAP file. IMEDIF 1035 uses a separate file for each process for multiplexing processing, and generates an IMS billing processing IPDR in the form of a file.

In the present specification, the meaning of the term used to describe an operation of transmitting and receiving data such as 'transmit', 'transmit and receive', and 'deliver' is not limited to an operation of directly transmitting and receiving data between a sender and a receiver. The above terms also include the operation of sending data through a storage device such as a database. For example, 'Sender A sends data X to receiver B' means' operation in which data X is transmitted through a direct connection between sender A and receiver B 'and' sender A stores data X in the database. Receiver B references data X from the database.

The apparatus and system described above may be implemented in hardware, software, or a combination thereof. In a hardware implementation, the modules used for charging the IMS system may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing units (DSPDs), programmable logic units (PLDs), field programmable A gate array (FPGA), a processor, a controller, a micro-controller, a microprocessor, another electronic unit designed to perform the functions described herein, or a combination thereof. The software may be implemented through a module that performs the functions described herein. Software code may be stored in memory units and executed by a processor. The memory unit may be implemented inside or outside the processor, in which case the memory may be coupled to the processor via various known means.

On the other hand, the method of the present invention as described above can be written in a computer program. And the code and code segments constituting the program can be easily inferred by a computer programmer in the art. In addition, the written program is stored in a computer-readable recording medium (information storage medium), and read and executed by a computer to implement the method of the present invention. And the recording medium includes all types of recording media (intangible medium such as a carrier wave as well as tangible media such as CD and DVD) readable by a computer.

The present invention described above is capable of various substitutions, modifications, and changes without departing from the technical spirit of the present invention for those skilled in the art to which the present invention pertains. It is not limited by the drawings.

1 is a configuration of the charging function of the IMS system according to the present invention.

2 is a simplified network diagram of an IMS system according to the present invention.

3 is a block diagram of the charging device 300 in the IMS system according to the present invention.

4 is a flowchart of a charging method in an IMS system according to the present invention.

5 is a detailed flowchart of the data generation step 430 for billing processing shown in FIG.

FIG. 6 is a detailed flowchart of the step 440 of calculating charging data shown in FIG. 4.

7 is a flowchart illustrating a step of filtering a charging request message according to an embodiment of the present invention.

8 is a flowchart illustrating a step of generating data for billing processing according to an embodiment of the present invention.

9 is a configuration diagram of a database for explaining charging processing data according to an embodiment of the present invention.

10 is a configuration diagram of a charging device according to an embodiment of the present invention.

FIG. 11 is a detailed block diagram of the charging data calculator 1033 according to an embodiment of the present invention shown in FIG. 10.

12 is a detailed block diagram of the IP charging data generator 1035 according to an embodiment of the present invention shown in FIG.

Claims (12)

In the charging method in the IMS (IP Multimedia Subsystem) system, Receiving a charging request message from the charging node; Detecting media type information from session description protocol (SDP) media information of the received billing request message; Detecting port information from the SDP media information of the received charging request message; Generating data for billing processing using the detected media type information and the detected port information; Calculating billing data using the billing processing data; Billing method to include. The method of claim 1, Generating the data for billing processing is Filtering the charging request message based on the functionality and role of the charging node; A billing method for generating billing processing data according to the filtering result. The method of claim 1, The billing processing data includes one or more of session information for each media or accounting information for each media. The method of claim 1, And generating IP charging data by using the calculated charging data. The method of claim 1, Computing the billing data Searching for media for which the session is terminated by using the data for billing processing; Calculating the charging data from the charging processing data according to the media search result; Billing method to include. 6. The method according to any one of claims 1 to 5, The charging request message is an accounting request (ACR) message according to the DIAMETER protocol. In the charging device in the IMS (IP Multimedia Subsystem) system, A message receiving unit for receiving a charging request message from the charging node; A media type detector for detecting media type information from session description protocol (SDP) media information of the received billing request message; A port detector for detecting port information from the SDP media information of the received billing request message; A billing processing data generation unit configured to generate billing processing data using the media type information and the media port information; A billing data calculator configured to calculate billing data using the billing data; Charging device including. The method of claim 7, wherein The billing processing data generation unit And a filtering unit to filter the charging request message based on the function and role of the charging node. A charging device for generating data for billing processing in accordance with the filtering result of the filtering unit. The method of claim 7, wherein The billing processing data includes one or more of session information for each media or accounting information for each media. The method of claim 7, wherein And an IP charging data generation unit for generating IP charging data using the calculated charging data. The method of claim 7, wherein The billing data calculation unit A media search unit for searching for media for which a session is terminated by using the data for billing processing; And a billing device for calculating the billing data from the billing processing data according to a search result of the media search unit. The method according to any one of claims 7 to 11, The charging request message is an accounting request (ACR) message according to the DIAMETER protocol.

Images