JP2008131086A - Ip communication system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently manage routing information from an execution server of basic services to an execution server of additional services. <P>SOLUTION: In an IP communication system, a first server providing basic services to user terminals transfers a request of additional services to a second server providing the additional services. A database stores a plurality of sets of routing information such as the necessity of transfer or transfer conditions which are identified by an identifier applicable irrespective of users, and stores a user profile composed of routing information unique to each user and the identifier of a routing information set applied to the user. The first server locally maintains all the sets of routing information, and upon receiving a request of additional services, the first server extracts the corresponding user profile from the database, and returns a part of the profile corresponding to its identifier to the set of routing information to determine the necessity of transfer. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to an IP communication system, and can be applied to, for example, an IMS (IP Multimedia Subsystem) network.

  Research and development of a multimedia communication system using SIP (Session Initiation Protocol) is underway, and the 3GPP multimedia communication system for examining next-generation mobile communication networks based on All-IP is IMS (IMS network). )is called. In the IMS network, additional services such as presence service and conference call are provided by an application server (hereinafter referred to as AS). For this reason, the S-CSCF (Serving Call Session Control Function), which is a central SIP server for providing services to users, receives the call when it recognizes that the call is requesting additional services. It is necessary to route a signal or the like to the AS and start a session with the AS. Initial filter criteria (hereinafter referred to as “iFC”) is used to recognize this additional service, but the S-CSCF uses iFC as a database for holding user authentication information and service information. Obtained from Home Subscriber Server) (see Non-Patent Document 1).

  Hereinafter, a series of registration operations of a user terminal (UE) including a process in which the S-CSCF acquires an iFC from the HSS and a process of routing using the iFC will be described with reference to FIG. In addition, in FIG. 2, the apparatus between a user terminal (UE) and S-CSCF is abbreviate | omitted.

  (T1) The UE 10 of the user A requests REGISTER registration to the S-CSCF 11 due to power-on or the like (S101). When the S-CSCF 11 receives the first REGISTER signal, the S-CSCF 11 does not have an authentication vector, and therefore obtains it from the HSS 12 and returns a 401 unauthorized response to request an authentication from the UE 10 (S102 to S104).

  (T2) Since the authentication is requested from the S-CSCF 11, the UE 10 transmits a REGISTER signal in which authentication information is set to the S-CSCF 11, whereby the S-CSCF 11 performs authentication and also sends the user service profile ( The user profile including iFC is fetched (S105 to S108). FIG. 3 shows an example of a user profile. In FIG. 3, the portion sandwiched between the tag <InitialFilterCriteria> and the tag </ InitialFilterCriteria> is iFC.

  (T3) The S-CSCF 11 holds the iFC while the user A is registered (a period in which REGISTER is valid). If a request signal is received during this holding period, the S-CSCF 11 uses this iFC and whether there is an additional service. (Necessity of routing to AS) is determined (S109).

  (T4) The S-CSCF 11 compares the content of the REGISTER signal (see S105) received from the user A with the iFC of the user A (S110), and when routing to the AS 13 is necessary, the UE 10 receives the REGISTER signal. A response (200 OK) is returned, and the REGISTER signal is routed to the AS 13 (S111, S112).

  (T5) After this, when the S-CSCF receives a request signal related to user A (transmission from user A or transmission to user A), the content of the signal and iFC are the same as in (T4) above. To determine whether or not routing to the AS 13 is necessary.

  However, in the above method, it is necessary to describe AS routing conditions for all additional services in the iFC in the service profile of each user, and the following problems P1 to P3 exist.

  P1: The amount of communication data between the S-CSCF and the HSS increases and affects traffic.

  P2: Since the information held in the S-CSCF increases, a large amount of S-CSCF resources are consumed.

  P3: It is necessary to change the iFC of all users when a change of service conditions or the like occurs (for example, change of SIP URL of AS).

  In order to solve these problems, the Shared Initial Filter Criteria function (hereinafter referred to as SiFC function) is defined as an optional function. In the SiFC function, data common to a plurality of users is stored in advance in the S-CSCF (locally stored), and only the identifier of the common data is set in the service profile of each user. It is possible to obtain information similar to that in the case of setting the user's iFC and downloading with the S-CSCF.

FIG. 4 shows a detailed image of the SiFC function. Shared iFC sets (301) can be described in the user's service profile (301 in FIG. 4A), and by specifying the identifier of the Shared iFC sets in the service profile (FIG. 4). (B) 302), among a plurality of iFC sets (303 in FIG. 4C) held locally in the S-CSCF, a corresponding identifier set (304 in FIG. 4C) is obtained. This set can be combined with iFC (305 in FIG. 4B) for each user to form AS routing information (306 in FIG. 4D).
3GPP TS 29.228 V7.0.0 (IP Multimedia (IM) Subsystem Cx and Dx Interfaces: Signaling flows and message content)

  However, 3GPP does not define details about the iFC creation method and the S-CSCF retention method. Therefore, there is a problem of how to manage the routing information to the application server efficiently.

  The present invention has been made in view of the above points, and intends to provide an IP communication system that can efficiently manage routing information to an additional service execution server and that the basic service execution server can quickly acquire the routing information. It is a thing.

  In order to solve this problem, the present invention includes a basic service execution server that provides a basic service to a user terminal, and an additional service execution server that provides an additional service to the user terminal. However, when the received service request is a request related to an additional service, the IP communication system transfers the service request to the corresponding additional service execution server when transfer is necessary according to the stored contents of the routing information management database. 1) The routing information management database includes (1-1) information applicable to any user, whether or not a service request may be transferred to the additional service execution server, conditions for transfer, and the like. A plurality of sets of routing information identified by a set identifier, and (1-2) each user At least a service profile including routing information unique to the user and a set identifier assigned to a set of routing information applied to the user. (2) The basic service execution server includes: (2-1) Download all sets of the routing information from the routing information management database and store them locally. (2-2) If the received service request is a request related to an additional service, The service profile of the user related to the received service request is fetched from the routing information management database, and the set identifier portion is routed based on the description of the set identifier of the service profile and all the sets of routing information held locally. To the user Together with routing information Yes, and judging the necessity of transfer of the corresponding received service request to said additional service executing server.

  According to the present invention, since the routing information management database centrally manages the routing information, the routing information to the additional service execution server can be efficiently managed, and the basic service execution server can quickly acquire the routing information. .

(A) Embodiment Hereinafter, an embodiment in which an IP communication system according to the present invention is applied to an IMS network will be described in detail with reference to the drawings.

(A-1) Configuration of Embodiment FIG. 5 is a block diagram illustrating a configuration example of an IMS network according to the embodiment. In FIG. 5, the IMS network 1 includes user terminals (UEs) 2-1, 2-2, P-CSCF (Proxy Call Session Control Function) 3, I-CSCF (Interrogating Call Session Control Function) 4-1, 4-. 2, S-CSCFs 6-1 to 6-3, HSS 7, and application server (AS) 8.

  The user terminals (UE) 2-1 and 2-2 may be either wireless terminals or wired terminals, and request services from the network side and receive provision of services. If the user terminals 2-1 and 2-2 are wireless terminals, they are accommodated in the P-CSCF 3 via an access point device (not shown). Since the user terminals 2-1 and 2-2 do not have the feature of this embodiment, the detailed configuration thereof is omitted.

  The P-CSCF 3 is a CSCF that is connected first for the user terminal 2 (2-1, 2-2) to access the network. The P-CSCF 3 plays a role of a so-called outbound proxy server for the user terminal 2. The user terminal 2 connected to the network transmits / receives all SIP messages via the P-CSCF 3 assigned at that time, and the P-CSCF 3 encrypts messages with the user terminal 2. It also plays a role of checking the validity of the header set by the user terminal 2 and ensuring that an unauthorized message is not transmitted to the network. Since the P-CSCF 3 does not have the characteristics of this embodiment, the detailed configuration thereof is omitted.

  The I-CSCFs 4-1 and 4-2 are proxy servers for exchanging SIP messages with other networks. The I-CSCFs 4-1 and 4-2 mainly play a role of transferring a message to an appropriate S-CSCF 3 in the own network from the content of the received message. In the case of this embodiment, the detailed configuration and processing of the I-CSCFs 4-1 and 4-2 are the same as those of the conventional one, and the description thereof is omitted.

  Also in this embodiment, the S-CSCF 6 (6-1 to 6-3) is basically a central SIP server for providing various services to the user, and the HSS 7 is a user authentication. It is a user management database that holds information, service information (see FIG. 1 to be described later), and the application server 8 provides additional services such as presence service and conference call.

  However, in this embodiment, S-CSCFs 6-1 to 6-3 and HSS 7 are different from the conventional ones. This will be described below. The S-CSCF 6 (6-1 to 6-3) is configured by one or a plurality of information processing apparatuses having a communication function in terms of hardware, but functionally described below. The function is configured to be realized, and the function is mainly executed by an installed application program. Similarly, the HSS 7 is configured by one or a plurality of information processing apparatuses having a communication function in terms of hardware, but functionally configured to realize the functions described below. The function is mainly executed by an installed application program.

  In the following description, the S-CSCFs 6-1 and 6-2 are S-CSCFs that support the SiFC function, and the S-CSCFs 6-3 are S-CSCFs that do not support the SiFC function.

  With respect to information for routing signals to the application server 8 by these S-CSCFs 6-1 to 6-3, all data serving as masters are set in the HSS 7. Further, regarding the SiFC function, data held locally by the S-CSCF 6 (6-1 to 6-3) is also managed by the HSS 7, and the S-CSCF 6 acquires data from the HSS 7 when necessary. Furthermore, iFC for each user is downloaded from the HSS 7 when the user terminal 2 of each user registers in the S-CSCF 6, and a request signal is transmitted from the user terminal 2 or another network 5 to the S-CSCF 6. In this case, the S-CSCF 6 determines the routing to the application server 8 from these pieces of information.

  FIG. 1 shows information INF1 to INF4 related to routing to the application server 8 held by the HSS 7.

INF1: SFC Function Correspondence Table of S-CSCF The SiFC function correspondence table INF1 shown in FIG. 1A describes whether or not each S-CSCF 6-1 to 6-3 is compatible with the SiFC function. It is.

  Since the SiFC function is an optional function, the SiFC set function is not used in the S-CSCF 6-3 that does not have a SiFC compatible function. For this reason, since there is a difference in the contents of the user profile transmitted from the HSS 7 to the S-CSCF 6 depending on the presence or absence of correspondence, the HSS 7 grasps the correspondence status of the SiFC function of each S-CSCF 6-1 to 6-3.

INF2: Additional Service / SiFC Set Correspondence Table The additional service / SiFC set correspondence table INF2 shown in FIG. 1B associates the identifier of the SiFC set for each type of additional service. In the example of FIG. 1B, “presence service” is associated with the identifier “2”.

  In this embodiment, a SiFC set is set for each additional service. By setting for each additional service, it is possible to set without affecting the setting of other SiFC sets when adding, changing, or deleting the additional service. In addition, if the user makes an additional service additional contract, it can be dealt with by simply adding the identifier of the corresponding SiFC set to the service profile of the user.

INF3: SiFC Set Data Group As shown in FIG. 1C, one or a plurality of iFC (Initial Filter Criteria) data is set in each SiFC set distinguished by an identifier. For example, one or a plurality of iFC (data) related to “presence service” is described in the SiFC set with the identifier “2”.

INF4: Service Profile Group As shown in FIG. 1D, in this embodiment, the service profile associated with each user describes a unique iFC associated with that user and the identifier of the SiFC set associated with that user. Has been.

  The routing conditions and routing information unique to the user are described in the unique iFC, but if there is no unique routing conditions and routing information, the unique iFC is not set. In the identifier of the SiFC set related to the user, the identifier of the SiFC set corresponding to the additional service with which the user has a contract is set.

  Information INF <b> 1 to INF <b> 4 related to routing to the application server 8 that is managed and held by the HSS 7 can be appropriately updated by an operation of the administrator or the like with respect to the HSS 7 or arrival information from an external device. Hereinafter, changes in the information INF1 to INF4 when the additional service is added and changes in the information INF1 to INF4 when the new user is added will be described in this order.

  A maintenance / management terminal (not shown) connected to HSS 7 or HSS 7 directly or via a communication network includes a program for updating the above-described routing information INF1 to INF4. The information INF1 to INF4 managed and held by the HSS 7 can be updated (edited) by performing an input operation using the input unit on the update screen displayed on the display unit of the maintenance / management terminal. it can. Further, information INF1 to INF4 managed and held by the HSS 7 may be updated (edited) based on information given from a provisioning system or the like.

  FIG. 6 is an explanatory diagram showing a state of fluctuation (setting) of routing information INF1 to INF4 when an additional service is added in the IMS network 1.

  For the SiFC set data INF group 3, SiFC set data 601 used in the additional service to be added is set with an unused SiFC set identifier. Thereafter, the additional service and the SiFC set identifier are added in association with the additional service / SiFC set correspondence table INF2. FIG. 6 shows that three types of iFCs related to the incoming billing service are set as SiFC set data 601 by assigning an unused identifier “11”, and for the additional service / SiFC set correspondence table INF2, “ An example is shown in which the identifier “11” is set in association with “incoming billing service”.

  Although illustration is omitted, when canceling the additional service, the administrator or the like deletes the information on the line related to the additional service to be canceled from the additional service / SiFC set correspondence table INF2, and the SiFC set data INF group 3 The SiFC set data related to the additional service to be canceled is also deleted. However, in the case of deletion, it is necessary that it is possible to delete that all users have not contracted for the corresponding service (the corresponding SiFC identifier is not set in the SiFC set of the service profile of all users) As a condition). If there is a user with a contract for the corresponding service and approval is given to the cancellation, the SiFC identifier of the SiFC data set of the additional service to be canceled is deleted from the service program file of the corresponding user in the service profile group INF4. To do.

  FIG. 7 is an explanatory diagram showing a state of change (setting) of information INF1 to INF4 related to routing when a new user is added.

  Provision conditions for additional services for new users and user-specific operating conditions are transmitted to the HSS 7 together with other necessary data (user ID, etc.) from the provisioning system or the like. For example, it is supplied as a scheduled process (for example, scheduled process several times a day). In the HSS7, when there is a contract for an additional service in the incoming data of a new user, the SiFC set identifier corresponding to the contract additional service is acquired from the additional service / SiFC set correspondence table INF2, and the SiFC set of the user profile is obtained. Set in the identifier field. If the new user has unique conditions, the iFC for that user is created and set.

  Although illustration is omitted, even when an additional service is added to or deleted from an existing user, the SiFC identifier corresponding to the additional service is added to or deleted from the SiFC set column of the user profile file. Realize.

(A-2) Operation of Embodiment Next, processing when the S-CSCF 6 in the IMS network 1 of this embodiment acquires routing information to the application server 8 will be described.

  FIG. 8 is a sequence diagram when the S-CSCF 6-1 compatible with the SiFC function initially collects (acquires) SiFC set data. Note that the S-CSCF 6-3 that does not support the SiFC function does not execute the collection process illustrated in FIG.

  (T11) The S-CSCF 6-1 compatible with the SiFC function requests SiFC set data from the HSS 7 according to the application when the application starts (S801).

  (T12) The HSS 7 confirms that the requesting S-CSCF 6-1 is an S-CSCF compatible with the SiFC function (see FIG. 1 (A)), and then data of all SiFC sets (FIG. 1 (C )) Is transmitted (S802).

  (T13) The S-CSCF 6-1 receives the data from the HSS 7, and when the setting is normally completed in its local database, the S-CSCF 6-1 starts the function as the S-CSCF and receives the SIP signal from the user. Start (S803).

  FIG. 9 is a sequence diagram when supplying SiFC set data added to the S-CSCF 6-1 compatible with the SiFC function. In FIG. 9, the identifier of the added SiFC set data is represented by “X + 1”.

  (T21) When the SiFC set data is added to the HSS 7 due to the addition of an additional service or the like (S901), the HSS 7 sends all the S-CSCFs (6-1, 6-2) corresponding to the SiFC function; 9 shows only the change of the SiFC set data group (S902).

  (T22) The S-CSCFs 6-1 and 6-2 that have received the change notification request SiFC set data to the HSS 7 (S903).

  (T23) The HSS 7 transmits SiFC set data to the requested S-CSCF 6-1 and 6-2 (S904), and the S-CSCF 6-1 and 6-2 receive the data from the HSS 7 and To the local database (S905). When the transmission is completed for all the S-CSCFs 6-1 and 6-2, the added additional service becomes valid, and a contract for the additional service can be added to each user.

  FIG. 10 is a sequence diagram illustrating a UE registration operation including a process in which the S-CSCF supporting the SiFC function downloads routing information to the application server.

  (T31) As described above, the S-CSCF 6-1 compatible with the SiFC function that can be accessed by the user terminal 2 loads the SiFC set data from the HSS 7 when the application is started.

  (T32) When the S-CSCF 6-1 receives the REGISTER signal from the user terminal 2 (S1001), the S-CSCF 6-1 performs user authentication in cooperation with the HSS 7 and requests the service profile of the user at the time of this authentication. (S1002, S1003).

  (T33) At this time, the HSS 7 confirms that the request source S-CSCF 6-1 is compatible with the SiFC function, and returns the user profile set in the HSS 7 to the S-CSCF 6-1 as it is (S1004). . That is, the HSS 7 returns the iFC unique to the user and the SiFC set identifier indicating the additional service subscribed to by the user. When the request source S-CSCF 6-1 does not support the SiFC function, only the user-specific iFC is returned.

  (T34) The S-CSCF 6-1 responds to the reception of the REGISTER signal to the user terminal 2, and the content of the REGISTER signal and the content of the user profile (user-specific iFC and SiFC set data related to the SiFC set identifier) (S1005), if routing to the application server 8 is necessary, the REGISTER signal is routed to the application server 8 (S1006).

  (T35) Although omitted in FIG. 10, the S-CSCF 6-1 compatible with the SiFC function will continue to be described above when there is a signal related to the user (transmission from the user or transmission to the user). Similarly to (T32) to (T34), the contents of the signal and the contents of the user profile (user-specific iFC and SiFC set data related to the SiFC set identifier) are compared, and the necessity of routing to the application server 8 is determined. decide.

  FIG. 11 is a sequence diagram illustrating a UE registration operation including a process in which an S-CSCF that does not support the SiFC function downloads routing information to an application server.

  (T41) It is assumed that the S-CSCF that can be accessed by the user terminal 2 is an S-CSCF 6-3 that does not support the SiFC function.

  (T42) When receiving the REGISTER signal from the user terminal 2 (S1101), the S-CSCF 6-3 performs user authentication in cooperation with the HSS 7 and requests the service profile of the user at the time of this authentication. (S1102, S1103).

  (T43) At this time, the HSS 7 confirms that the S-CSCF 6-3 of the request source does not support the SiFC function, confirms the service profile of the corresponding user with the HSS 7, and corresponds to the SiFC set identifier in the service profile. SiFC set data to be collected is collected, and the collected data and the iFC unique to the user are combined and returned to the S-CSCF 6-3 as the contents of the user's service profile (iFC whole) (S1104).

  (T44) The S-CSCF 6-3 responds to the reception of the REGISTER signal to the user terminal 2, and the content of the REGISTER signal and the content of the user profile (user-specific iFC and SiFC set data related to the SiFC set identifier) (S1105), and if routing to the application server 8 is necessary, the REGISTER signal is routed to the application server 8 (S1106).

  (T45) Although omitted in FIG. 11, the S-CSCF 6-3 that does not support the SiFC function will be described above when there is a signal related to the user (transmission from the user or transmission to the user). Similarly to (T42) to (T44), the contents of the signal and the contents of the user profile are compared, and the necessity of routing to the application server 8 is determined.

(A-3) Effect of Embodiment As described above, according to the above-described embodiment, it is possible to centrally manage routing information to the application server with the HSS even when the SiFC function is performed, and to set information Can reduce the management procedure. That is, it is possible to reduce information that must be operated by an administrator or the like when the number of additional services increases or decreases, or when users increase or decrease.

  In addition, according to the above embodiment, by creating SiFC set data for each additional service, it is only necessary to increase or decrease the data of the corresponding service when changing the setting of the routing information to the application server due to increase or decrease of the additional service, Setting is possible without affecting data of other additional services. Furthermore, even when a contract service for a user is added, etc., it is possible only by setting the SiFC identifier of the corresponding service in the SiFC set data of each user profile.

  As described above, in the above-described embodiment, it is possible to simplify the data setting procedure when changing (adding, deleting, changing) an additional service, and to obtain an effect that data setting can be performed flexibly.

(B) Other Embodiments In FIG. 5, one application server is shown, but it goes without saying that there may be a plurality of application servers. Similarly, there may be a plurality of HSSs. However, it is necessary that there is one HSS corresponding to each S-CSCF.

  In the above-described embodiment, the information INF1 to INF4 that characterize this embodiment is shown in the HSS. However, the information may be stored in a database different from the HSS.

  Moreover, although the case where the IP communication system according to the present invention is applied to an IMS network has been described in the above embodiment, the present invention can also be applied to other networks. However, there is a basic service execution server (corresponding to the S-CSCF of the embodiment) and an additional service execution server (corresponding to the application server of the embodiment), and the service request received by the basic service execution server is a request related to the additional service. In some cases, it is necessary to be an IP communication system that transfers a service request to an additional service execution server.

It is explanatory drawing which shows the information regarding the routing to an application server which HSS of embodiment holds. It is a sequence diagram which shows a series of registration operation | movement of the conventional user terminal (UE). It is explanatory drawing which shows the image of an example of the conventional service profile for every user. It is explanatory drawing which shows the detailed image of the conventional SiFC function. It is a block diagram which shows the structural example of the IMS network which concerns on embodiment. It is explanatory drawing which shows the mode of the fluctuation | variation (setting) of the information regarding routing in the case of adding the additional service of embodiment. It is explanatory drawing which shows the mode of the fluctuation | variation (setting) of the information regarding routing at the time of the addition of the new user of embodiment. It is a sequence diagram when the S-CSCF of the embodiment initially collects (acquires) SiFC set data. It is a sequence diagram at the time of acquiring SiFC set data to which the S-CSCF of the embodiment is added. It is a sequence diagram which shows a series of registration operation | movement of a user terminal (UE) including the process which S-CSCF corresponding to SiFC function of embodiment downloads the routing information to an application server. It is a sequence diagram which shows a series of registration operation | movement of a user terminal (UE) including the process which S-CSCF of non-SiFC function support of embodiment downloads the routing information to an application server.

Explanation of symbols

  1: IMS network, 2-1, 2-2: User terminal (UE), 3: P-CSCF, 4-1, 4-2: I-CSCF, 6-1 to 6-3: S-CSCF, 7 : HSS, 8: Application server (AS), INF1: Si-FC function correspondence table of S-CSCF, INF2: Additional service / SiFC set correspondence table, INF3: SiFC set data group, INF4: Service profile group.

Claims (3)

A basic service execution server that provides a basic service to a user terminal; and an additional service execution server that provides an additional service to the user terminal. The basic service execution server receives a service request related to the additional service. In the case of a request, according to the contents stored in the routing information management database, if transfer is necessary, in the IP communication system that transfers the service request to the corresponding additional service execution server,
The routing information management database is
Multiple sets identified by set identifiers of routing information that can be applied regardless of the user, including information on whether or not the service request can be transferred to the additional service execution server and conditions for transferring the request. When,
For each user, at least a service profile consisting of routing information unique to the user and a set identifier assigned to a set of routing information applied to the user is stored,
The basic service execution server is
Download all the routing information sets from the routing information management database and keep them locally.
When the received service request is a request related to an additional service, the service profile of the user related to the received service request is fetched from the routing information management database, a description of the set identifier of the service profile and the routing information stored locally Based on all sets, the set identifier part is returned to the routing information, and the necessity of transferring the received service request to the corresponding additional service execution server is determined together with the routing information unique to the user. IP communication system. A second basic service execution server that cannot support the set of routing information,
When a service profile of a specific user is requested from the second basic service execution server, the routing information management database includes a description of a set identifier of the service profile and all the stored routing information sets. Based on this, the set identifier part is returned to the routing information, along with the routing information unique to the user, and returned to the second basic service execution server,
The second basic service execution server determines necessity of transfer of a received service request to the additional service execution server based on routing information returned from the routing information management database. The IP communication system according to 1.   3. The IP communication system according to claim 1, wherein the set of routing information is provided for each type of additional service.

Images