JP2015159516A - policy control system and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a policy control system which easily cancels the inconsistency of policy states among each device for controlling a policy.SOLUTION: In a policy control system 1, a policy management device 100 receives a state match command, which includes the state information of a service policy owned by an opposite device, from the opposite device which is a packet header identification control device 200 or an application identification device 300, periodically or at least one timing among when restored from each fault. On detection of a difference as a result of a comparison of the state information extracted from the received state match command with state information which includes the service policy owned by the self-device 100, the policy management device 100 controls the opposite devices 200, 300 to add or delete information corresponding to the detected difference among the state information of the service policies owned by the opposite devices 200, 300.

Description

  The present invention relates to a policy control system and program for controlling a policy set for performing charging control and flow control.

  In 3GPP (3rd Generation Partnership Project), policy and charging control are defined (see Non-Patent Document 1). Here, the policies are PCC rules (Policy and Charging Control Rules) and ADC rules (Application Detection and Control Rules) defined in 3GPP. , Set to perform charging control and flow control.

  In 3GPP, a PCRF device, a PCEF device, and a TDF device are defined, and each is configured by an independent device and connected by an interface. Here, the PCRF device (Policy and Charging Rule Function) is a policy and charging rule function. A PCEF device (Policy and Charging Enforcement Function) is a policy and charging implementation function. A TDF device (Traffic Detection Function) is a traffic detection function.

A Gx interface is defined as an interface between the PCRF device and the PCEF device. In Gx, when the PCEF device detects an external trigger, the PCEF device requests a policy from the PCRF device, and the PCRF device sets a PCC rule according to the request.
An Sd interface is defined as an interface between the PCRF device and the TDF device. In Sd, when the TDF device requests a policy from the PCRF device or from the PCEF device, the PCRF device sets an ADC rule for the TDF device according to the request.

  Conventionally, there are billing services (for example, pay-per-use billing services) and additional services (parental control), and policies are closely related to user billing control and flow control. Since the PCC rules and ADC rules possessed by each device are not allowed to fall into a state mismatch between the devices, policy and charging control are defined. However, when the PCRF device, the PCEF device, and the TDF device fail or an interface disconnection occurs, there are cases where policies (PCC rules and ADC rules) held by the devices do not match.

  Conventionally, every time the PCC rule or ADC rule increases, it is necessary to input the rule to the PCRF device, the PCEF device, and the TDF device. Further, in the dynamic setting (adaptive setting, dynamic setting) which is an advantage of the policy, the following message is transmitted and received. For example, the PCEF device requests a policy (PCC rule) to be applied to the subscriber A, for example, by transmitting a CCR (Credit-Control-Request) message to the PCRF device. In accordance with the request, the PCRF device, for example, a policy (PCC rule) to be applied to the subscriber A extracted from the four policies to be applied to the subscribers A, B, C, and D held by the CCF (Credit-Control- Answer) is sent to the PCEF device. Therefore, in the Dynamic setting, a mismatch occurs in the policy state held by each device.

  In the prior art, in order to solve the problem that the policies (PCC rules and ADC rules) held by each device do not match, a PCC rule is set pre-defined to the PCEF device, and also to the TDF device. An implementation has been implemented in which an ADC rule is set with pre-diffused, and each device is made redundant, thereby reducing inconsistencies.

3GPP TS 29.213 V12.1.0 (2013-09) Policy and Charging Control signaling flows and Quality of Service (QoS) parameter mapping (Release 12)

  However, in the conventional method in which rules are set pre-defined to a PCEF device or the like, for example, although the PCEF device is set in a state in which the rules themselves are held in advance, policy execution (applying a policy to a user) or To delete a policy (cancellation of a policy applied to a user), a message notification for controlling ON / OFF from the PCRF device is required. Specifically, the following message is transmitted and received.

  For example, it is assumed that the PCEF device has four policies (PCC rules) to be applied to subscribers A, B, C, and D in pre-defined. This PCEF device sends a CCR message to the PCRF device, thereby requesting that the PCC rule applied to the subscriber A be made valid (ON). In accordance with the request, the PCRF device transmits a CCA message or RAR (Re-Auth-Request) message for enabling (ON) the PCC rule applied to the subscriber A to the PCEF device. For this reason, for example, when the PCEF device fails, it is necessary to set again to enable (ON) the PCC rule from the PCRF device.

  Further, for example, when the PCEF device resumes the interrupted communication (when the PCEF device is resumed), the PCEF device transmits CCR-Is corresponding to the number of accommodated simultaneous connection sessions to the PCRF device. . CCR-I indicates a CCR message in which “INITIAL_REQUEST” is set in CC-Request-Type AVP.

  For example, when the PCRF device resumes the interrupted communication (when the PCRF device is resumed), the PCEF device does not apply the policy until CCR-I is transmitted. At this time, if the value of “origin-state-id” is updated in the CCA message of the PCRF device, the PCEF device starts the message from a CER (Capabilities-Exchange-Request) message. Therefore, CCR-Is for all currently connected sessions are transmitted to the PCRF device from all the PCEF devices accommodated in the PCRF device. In this case, since the PCRF apparatus performs policy setting with the same number of CCA messages after processing them, the PCRF apparatus falls into an overload state.

  The present invention has been made in view of such a background, and an object of the present invention is to provide a policy control system that easily resolves a policy state inconsistency between devices that control policies.

  In order to solve the above-described problems, a policy control system according to the present invention comprises a policy management apparatus that sets a policy of a service for predetermined apparatuses that are communicably connected to each other, and the predetermined apparatus constitutes a flow. An application identification device that identifies a data portion of a packet according to a set service policy, and a packet header identification control device that transfers a flow that is the predetermined device and matches the set service policy to the application identification device; A policy control system comprising a plurality of devices including the policy management device, from the opposing device that is any one of the predetermined devices, at least one of the periodic management and at the time of recovery from a failure, Contains the status information of the policy of the service held by the opposite device When the state matching command is received, and when the difference is detected by comparing the state information extracted from the received state matching command with the state information including the policy of the service held by the own device, the held by the opposite device Information corresponding to the detected difference is added or deleted from the status information of the service policy to the opposing device.

  According to this configuration, the policy control system matches the status information including the policy of the service held by the opposite device of the policy management device with the information held by the policy management device at a predetermined timing. Policy state inconsistency can be easily resolved without doing so.

  In order to solve the above-described problem, a policy control system according to the present invention includes a policy management apparatus that sets a service policy for predetermined apparatuses that are communicably connected to each other, and the predetermined apparatus that performs a flow. An application identification device that identifies a data portion of a packet to be configured according to a set service policy, and a packet header identification control device that transfers a flow that is the predetermined device and matches the set service policy to the application identification device And the packet header identification control device receives the policy from the policy management device periodically and at least at one of the timings of recovery from the failure. Policy status information of the service held by the management device If the difference is detected by comparing the state information extracted from the received state matching command with the state information including the policy of the service held by the own device, the state matching command is held by the own device. The information corresponding to the detected difference is added or deleted from the policy policy status information.

  According to such a configuration, in the policy control system, the packet header identification control device matches the state information including the policy of the service held by the own device with the information held by the policy management device at a predetermined timing. Policy state inconsistency can be easily resolved without any intervention.

  According to the present invention, it is possible to easily resolve a policy inconsistency between devices that control a policy.

It is a block diagram which shows the structure of the policy control system and peripheral system which concern on 1st Embodiment of this invention. It is a sequence diagram which shows the flow of cancellation of a state mismatch in the policy control system which concerns on 1st Embodiment of this invention. FIG. 3A and FIG. 3B are diagrams showing a processing flow when a state matching command is transmitted from the packet header identification control device to the policy management device. FIG. 4A to FIG. 4C are diagrams showing a process flow when a state matching command is transmitted from the policy management apparatus to the packet header identification control apparatus. FIG. 5A and FIG. 5B are diagrams illustrating a processing flow when a state matching command is transmitted from the application identification apparatus to the policy management apparatus. FIG. 6A and FIG. 6B are diagrams showing the flow of processing when a state matching command is transmitted from the application identification device to the packet header identification control device. It is a block diagram which shows typically the structure of the policy control system which concerns on 2nd Embodiment of this invention. It is a sequence diagram which shows an example of the flow of a process in the policy control system of FIG. It is a block diagram which shows typically the structure of the policy control system which concerns on 3rd Embodiment of this invention. It is a sequence diagram which shows an example of the flow of a process in the policy control system of FIG. It is a block diagram which shows typically the structure of the policy control system which concerns on 4th Embodiment of this invention. It is a sequence diagram which shows an example of the flow of a process in the policy control system of FIG. It is a block diagram which shows typically the structure of the policy control system which concerns on 5th Embodiment of this invention. It is a sequence diagram which shows an example of the flow of processing in the policy control system of FIG. It is a block diagram which shows typically the structure of the policy control system which concerns on 6th Embodiment of this invention. It is a sequence diagram which shows an example of the flow of a process in the policy control system of FIG.

Hereinafter, the policy control system of the present invention will be described in detail with reference to the drawings.
(First embodiment)
As shown in FIG. 1, the policy control system 1 includes a plurality of devices including a policy management device 100, a packet header identification control device 200, and an application identification device 300.

The policy management apparatus 100 sets a service policy for a predetermined apparatus connected to be communicable with each other. Here, the service refers to a billing service (eg, pay-per-use billing service) or an additional service (parental control). A policy is a PCC rule or an ADC rule.
The PCC rule includes, for example, a rule name, service identifier, service data flow filter (s), and the like.
The ADC rule includes, for example, a rule identifier, TDF application identifier, precedence, and the like.
The policy management apparatus 100 corresponds to a PCRF defined by 3GPP. In the drawings, the policy management apparatus 100 may be simply referred to as the management apparatus 100.

  The packet header identification control device 200 is a predetermined device communicably connected to the policy management device 100, and transfers a flow that matches the set service policy to the application identification device 300. The packet header identification control device 200 is provided in the gateway 700 and controls the flow of the IP (Internet Protocol) network 2. The packet header identification control device 200 realizes 5-tuple-based flow control. “5tuple” is a set of a transmission source IP address, a transmission destination IP address, a transmission source port number, a transmission destination port number, and a protocol number. The packet header identification control device 200 corresponds to PCEF defined by 3GPP. In the drawings, the packet header identification control device 200 may be simply referred to as the control device 200 in some cases.

  The application identification device 300 is a predetermined device that is communicably connected to the policy management device 100, and identifies the data portion of the packet that constitutes the flow according to the set service policy. The application identification device 300 realizes application detection by L7 analysis. That is, the packet is identified based on the data of the network layer L7 (application layer). The application identification device 300 corresponds to TDF defined by 3GPP. In the drawings, the application identification device 300 may be simply referred to as the identification device 300 in some cases.

The packet header identification control device 200 and the application identification device 300 cooperate to function as a DPI device (Deep Packet Inspection).
Further, by providing the application identification device 300 in the gateway 700, the packet header identification control device 200 and the application identification device 300 can be configured as an integrated device that does not worry about interface disconnection. In this case, the gateway 700 is connected to the policy management apparatus 100 through the Gx interface and the Sd interface specified by 3GPP.

  FIG. 1 illustrates a group of devices defined by 3GPP as a peripheral system of the policy control system 1. A subscriber database 810, an online charging system 820, an access network gateway 840, and an application server 850 are connected to the policy management apparatus 100 through different interfaces. Among these, the online charging system 820 is connected to the packet header identification control device 200 and the application identification device 300 by separate interfaces in addition to the policy management device 100. The offline charging system 830 is not connected to the policy management apparatus 100 but is connected to the packet header identification control apparatus 200 and the application identification apparatus 300 through different interfaces.

[Status matching command]
In the policy control system 1 according to the first embodiment of the present invention, a state matching command is notified in order to check whether the states are consistent between the devices that control the policy. The state matching command is a message for checking whether the state is consistent between the devices that control the policy.

  The transmission source of the state matching command may be any of the policy management device 100, the packet header identification control device 200, and the application identification device 300. The state matching command includes a key information list of policy states currently held in the transmission source device. Here, the state key information list includes, for example, rule name, Subscription-ID, Framed-Ip-Address, Session ID, and the like. For example, when five policies applied to subscribers A, B, C, D, and E are held, a state matching command including a key information list indicating the policy is referred to as a “state matching command (Subscription-ID: A, B, C, D, E) ”.

  Timing at which the status matching command including the policy held by the own device is matched with the opposite device between the device that is the source of the state matching command and the opposite device that is communicably connected to the source device (hereinafter referred to as the following) (Referred to as “matching timing”) may be periodic, when recovered from a failure, or both. In the case of periodicity, it can be determined according to the service, such as 1 minute interval or 5 minute interval.

  When the state matching command is periodically transmitted, a device that is the source of the state matching command can be a predetermined device such as the packet header identification control device 200 and the application identification device 300. If the state matching command is sent periodically, a watchdog command can be used. As the state matching command, a dedicated command for sending a state key information list or the like can be used.

[Flow for resolving status inconsistencies]
With reference to FIG. 2, description will be given of the flow of state mismatch resolution in the policy control system according to the first embodiment of the present invention. The packet header identification control device 200 detects the matching timing for matching the state information including the retained policy with the policy management device 100 (step S1). Then, the packet header identification control device 200 transmits a state matching command including the key information list of the currently held state to the policy management device 100 (step S2).

  The policy management apparatus 100 receives a state matching command including a key information list indicating the state information of the policy held by the counter apparatus from the counter apparatus which is the packet header identification control apparatus 200 (step S3). Then, the policy management apparatus 100 extracts a key information list from the state matching command received from the opposite apparatus (step S4). Then, the policy management apparatus 100 compares the extracted key information list with the state information of the policy currently held by the own apparatus (step S5).

  When the policy management apparatus 100 detects a difference as a result of the comparison, the policy management apparatus 100 transmits a message that causes the opposite apparatus to add or delete information corresponding to the detected difference among the policy state information held by the opposite apparatus (step S6). . Then, the packet header identification control device 200 adds or deletes information corresponding to the difference (step S7). Note that the policy management apparatus 100 ends the process when no difference is detected as a result of the comparison. Through the above processing flow, it is possible to resolve the policy state mismatch between the policy management apparatus 100 and the packet header identification control apparatus 200.

  A message transmitted and received by each device in the process of resolving the state mismatch shown in FIG. 2 will be described with reference to FIGS. 3 (a) and 3 (b). FIG. 3A is a flowchart showing a process flow of the policy management apparatus 100. The policy management apparatus 100 receives, for example, the above-described state matching command (Subscription-ID: A, B, C, D, E) at least at the timing of recovery from a failure at regular intervals. (Step S11). In this case, the policy management apparatus 100 determines whether or not there is a difference between the key information list extracted from this state matching command and the information held by the own apparatus (step S12). If there is no difference (step S12: No), the policy management apparatus 100 ends the process. On the other hand, when there is a difference (step S12: Yes), the policy management apparatus 100 transmits an RAR (Re-Auth-Request) message (step S13) and ends the process. In the RAR message, a policy is designated based on the same information as the specific information transmitted in the CCR-I message described later.

  FIG. 3B shows a typical processing flow when there is a difference. The packet header identification control device 200 transmits a state matching command (Subscription-ID: A, B, C, D, E) to the policy management device 100 (step S21). If there is a difference, the policy management apparatus 100 transmits an RAR message to the packet header identification control apparatus 200 (step S22). Then, the packet header identification control device 200 adds or deletes information corresponding to the difference, and transmits an RAA (Re-Auth-Answer) message to the policy management device 100 as a response (step S23).

  In the prior art, when the device of the policy management device 100 is restarted, the CCR-I message is transmitted from the packet header identification control device 200 to the policy management device 100 by the number of connections of all devices, so that the policy management device 100 is overloaded. There is a possibility of connection. On the other hand, according to the present embodiment, since the policy state inconsistency can be resolved in the operation state, only the differential PCC rule that the packet header identification control device 200 does not have can be added when the policy management device 100 restarts. Alternatively, it is possible to delete only the differential PCC rule. Therefore, the load on the policy management apparatus 100 can be reduced.

  Further, the same operation can be performed even if the device that has transmitted the state matching command is replaced with another device. In the following, a message to be transmitted / received in accordance with a variation of the apparatus that is the source of the state matching command will be described.

[When sending a status matching command from the policy management device]
FIG. 4A is a diagram illustrating a processing flow of the packet header identification control device 200 when a state matching command is transmitted from the policy management device 100 to the packet header identification control device 200. The packet header identification control device 200 receives the above-mentioned state matching command (Subscription-ID: A, B, C, D, E) periodically and at least at one of the times when it recovers from a failure. (Step S31). Then, the packet header identification control device 200 determines whether or not there is a difference between the key information list extracted from the state matching command and the information held by the own device (step S32). When there is no difference (step S32: No), the packet header identification control device 200 ends the process. On the other hand, when there is a difference (step S32: Yes), the packet header identification control apparatus 200 transmits a CCR-I message or a CCR-T message (step S33), and ends the process.
CCR-T indicates a CCR message in which “TERMINATION_REQUEST” is set in CC-Request-Type AVP.

  FIG. 4B is a diagram showing a processing flow when the holding status of the packet header identification control device 200 is smaller, that is, when the policy is lost in the packet header identification control device 200. The policy management apparatus 100 transmits a state matching command (Subscription-ID: A, B, C, D, E) (step S41). In this case, since the policy is lost, the packet header identification control apparatus 200 transmits a CCR-I message to request the policy (step S42). Specifically, in the CCR-I message, session-ID AVP / Origin-Host AVP / Origin-Realm AVP / Destination-Realm AVP / Auth-Application-Id AVP / Framed-Ipv6-prefix AVP / Logical-Access-ID Data indicating a session such as AVP, user, and flow is transmitted. Then, the policy management apparatus 100 determines (sets) the policy by assigning a policy to the corresponding packet header identification control apparatus 200 based on the above-described information included in the received CCR-I message (step) S43), a CCA (Credit-Control-Answer) -I message for designating a policy is transmitted (step S44). Thereby, the packet header identification control device 200 adds a policy and executes the policy.

  FIG. 4C is a diagram showing a processing flow when there are more possession statuses of the packet header identification control device 200, that is, when it is necessary to delete a session established in the packet header identification control device 200. The policy management apparatus 100 transmits a state matching command (Subscription-ID: A, B, C, D, E) (step S51). In this case, the packet header identification control apparatus 200 transmits a CCR-T message to delete the established session (specified by the Session ID) (step S52). This CCR-T message includes the Session ID of the corresponding session. The policy management device 100 recognizes the Session ID included in the received CCR-T message, and determines (deletes) the policy by deleting the corresponding session of the corresponding packet header identification control device 200 (step S53), A CCA message is transmitted as a response to the CCR-T message (step S54). Thereby, the packet header identification control device 200 deletes the corresponding session corresponding to the difference and executes the policy.

[When a status matching command is sent from the application identification device]
FIG. 5A is a diagram illustrating a processing flow of the policy management apparatus 100 when a state matching command is transmitted from the application identification apparatus 300 to the policy management apparatus 100. It is assumed that the policy management apparatus 100 receives a state matching command (Subscription-ID: A, B, C, D, E) periodically and at least at one of the times when the machine recovers from the failure (step) S61). Then, the policy management apparatus 100 determines whether or not there is a difference between the key information list extracted from this state matching command and the information held by the own apparatus (step S62). If there is no difference (step S62: No), the policy management apparatus 100 ends the process. If there is a difference (step S62: Yes), the policy management apparatus 100 transmits a TSR (TDF-Session-Request) message (step S63) and ends the process.

  FIG. 5B shows a typical processing flow when there is a difference. The application identification device 300 transmits a state matching command (Subscription-ID: A, B, C, D, E) (step S71). If there is a difference, the policy management apparatus 100 transmits a TSR message to the application identification apparatus 300 (step S72). Then, the application identification apparatus 300 adds or deletes information corresponding to the difference, and transmits a TSA (TDF-Session-Answer) message to the policy management apparatus 100 as a response (step S73).

[Process to resolve state mismatch in DPI device]
If the application identification device 300 and the packet header identification control device 200 functioning as a DPI device are not integrated devices but separate devices connected by a predetermined interface, there is a possibility of interface disconnection. Therefore, a process for periodically eliminating the state mismatch between the application identification device 300 and the packet header identification control device 200 is performed.

  FIG. 6A is a diagram illustrating a processing flow of the application identification device 300 when a state matching command is transmitted from the application identification device 300 to the packet header identification control device 200. The application identification device 300 transmits the above-described state matching command (Subscription-ID: A, B, C, D, E) to the packet header identification control device 200 (step S81). Then, the application identification device 300 determines whether or not a state matching command has been received from the packet header identification control device 200 (step S82). When the state matching command is received (step S82: Yes), the application identification apparatus 300 ends the processing assuming that the state is matched. On the other hand, if the state matching command is not received even after a predetermined time has elapsed (step S82: No), the application identification apparatus 300 determines that there is an abnormality such as a disconnection in the interface between the two apparatuses, and the policy management apparatus 100 On the other hand, a request is made to connect to another application identification device 300 (step S83).

  FIG. 6B shows a typical processing flow when there is no abnormality in the interface between the two devices. The application identification device 300 transmits a state matching command (Subscription-ID: A, B, C, D, E) to the packet header identification control device 200 (step S91). Then, within a predetermined time, the packet header identification control device 200 transmits a state matching command (Subscription-ID: A, B, C, D, E) to the application identification device 300 (step S92). Subsequently, within a predetermined time, the application identification device 300 transmits a state matching command (Subscription-ID: A, B, C, D, E) to the packet header identification control device 200 (step S91). Further, within a predetermined time, the packet header identification control device 200 transmits a state matching command (Subscription-ID: A, B, C, D, E) to the application identification device 300 (step S92). Thereafter, the same processing is performed. Thereby, it is possible to match the status information of the policy of the service held by each device.

  FIG. 6A shows the process of requesting connection switching when the application identification device 300 does not receive the state matching command. However, when the packet header identification control device 200 does not receive the state matching command, the connection is made. It is also possible to request switching.

(Second Embodiment)
FIG. 7 is a block diagram schematically showing the configuration of the policy control system according to the second embodiment of the present invention. As shown in FIG. 7, the policy control system 1B includes a policy management device 100, a plurality of packet header identification control devices 200a and 200b, and a plurality of application identification devices connected to the policy management device 100 in a communicable manner. 300a, 300b.

  The packet header identification control device 200a accommodates application identification devices 300a and 300b. The packet header identification control device 200b accommodates application identification devices 300a and 300b. The packet header identification control devices 200a and 200b share the application identification devices 300a and 300b. In FIG. 7, two packet header identification control devices 200 and two application identification devices 300 are illustrated, but three or more each may be used.

FIG. 8 is a sequence diagram showing an example of a process flow in the policy control system of FIG. The packet header identification control device 200a periodically transmits / receives a state matching command (Subscription-ID: A, B, C, D, E) to / from the application identification device 300a (step S101).
The packet header identification control device 200a periodically transmits / receives a state matching command (Subscription-ID: A, B, C, D, E) to / from the application identification device 300b (step S102).
The packet header identification control device 200b periodically transmits / receives a state matching command (Subscription-ID: A, B, C, D, E) to / from the application identification device 300a (step S103).
The packet header identification control device 200b periodically transmits / receives a state matching command (Subscription-ID: A, B, C, D, E) to / from the application identification device 300b (step S104).

  For example, it is assumed that a failure of the application identification device 300b has occurred (step S105). Here, the failure includes a failure of the application identification device 300b itself, a case where the interface between devices fails or is disconnected, and a case where both the device and the interface fail.

  In such a case, for example, the packet header identification control device 200a detects a failure of the application identification device 300b because the state matching command is not received from the application identification device 300b even after a predetermined time has elapsed (step S106). Then, the packet header identification control device 200a transmits a CCR message requesting the policy management device 100 to re-establish the session being connected to the application identification device 300b (step S107).

  Then, the policy management apparatus 100 transmits a TSR message for requesting addition of a session to another application identification apparatus 300a that has not failed (step S108). Then, the application identification device 300a returns a TSA message in response to the request from the policy management device 100 (step S109). Then, the policy management apparatus 100 returns a CCA message in response to the request to the packet header identification control apparatus 200a that has requested the re-establishment of the session (step S110).

  According to the policy control system 1B of the second embodiment, when the packet header identification control device 200a detects a failure of the application identification device 300b, it requests the policy management device 100 to allocate to another application identification device 300a. Since the rule setting is performed from the policy management apparatus 100 to another application identification apparatus 300a, switching of the application identification apparatus 300 can be realized in a short period of time. Therefore, when the application identification device 300b breaks down, a smooth call connection can be realized by another application identification device 300a.

(Third embodiment)
FIG. 9 is a block diagram schematically showing the configuration of the policy control system according to the third embodiment of the present invention. As shown in FIG. 9, the policy control system 1C is different from the policy control system 1B (see FIG. 7) in that it includes sorting devices 400a and 400b.
The distribution device 400a has one side connected to the packet header identification control device 200a and the other side connected to the application identification devices 300a and 300b.
The distribution device 400b has one side connected to the packet header identification control device 200b and the other side connected to the application identification devices 300a and 300b.

The distribution device 400a distributes the flow from the packet header identification control device 200a to the application identification device 300a or the application identification device 300b under the management of the policy management device 100.
The distribution device 400b distributes the flow from the packet header identification control device 200b to the application identification device 300a or the application identification device 300b under the management of the policy management device 100. In the following description, the sorting device 400 is described unless otherwise distinguished.

  FIG. 10 is a sequence diagram showing an example of a process flow in the policy control system of FIG. The processing from step S101 to step S104 is the same as the processing shown in FIG. That is, the packet header identification control device 200a (or 200b) and the application identification devices 300a and 300b transmit / receive state matching commands (Subscription-ID: A, B, C, D, E) to / from each other.

  Under the above assumption, for example, the packet header identification control device 200a detects a trigger such as an external distribution request signal (step S201). In this case, the packet header identification control device 200a transmits a CCR message requesting flow distribution to the policy management device 100 (step S202). Then, the policy management apparatus 100 transmits, to the application identification apparatus 300a, for example, a TSR message that allocates a session whose Subscription-ID is “A, B” (step S203). Then, the application identification apparatus 300a returns a TSA message that responds to the request from the policy management apparatus 100 (step S204).

  Although not shown, similarly, the policy management apparatus 100 transmits a TSR message that distributes, for example, sessions with Subscription-IDs “C, D, E” to another application identification apparatus 300b. Then, the policy management apparatus 100 includes a list including a plurality of pieces of key information for grouping flows and information of the application identification apparatus 300 assigned by the key information in the state matching command, and includes the state matching command (300a = Subscription-ID = A, B, 300b = Subscription-ID = C, D, E) is transmitted to the sorting apparatus 400a (step S205). Then, the distribution device 400a distributes the flow according to the set policy (step S206). Then, the policy management apparatus 100 returns a CCA message in response to the request to the packet header identification control apparatus 200a that requested the flow distribution (step S207).

  As shown in FIG. 9, when a plurality of application identification devices 300 have a scale-out configuration, the same call is required to be distributed to the same application identification device 300 as a requirement condition of the distribution method to the application identification device 300. The policy management apparatus 100 distributes the flow according to the resource of the application identification apparatus 300. For this purpose, the policy management apparatus 100 sets the application identification apparatus 300 determined by itself by using a TSR message, and notifies the packet header identification control apparatus 200 of the CCA message. Therefore, the packet header identification control device 200 can identify the application identification device 300 assigned by the policy management device 100 from the CCA message. However, in the conventional method, the distribution device 400 cannot recognize the application identification device 300 assigned by the policy management device 100.

  On the other hand, according to the policy control system 1C of the third embodiment, the policy management apparatus 100 assigns a state matching command including key information such as subscriber and information of the assigned application identification apparatus 300 to the state matching command. Transmit to the minute device 400. Therefore, the distribution apparatus 400 can distribute the same call to the same application identification apparatus 300 according to the information specified by the state matching command.

(Fourth embodiment)
FIG. 11 is a block diagram schematically showing the configuration of the policy control system according to the fourth embodiment of the present invention. As shown in FIG. 11, the policy control system 1D is different from the policy control system 1B (see FIG. 7) in that it includes redundant policy management devices 100a and 100b. The packet header identification control devices 200a and 200b and the application identification devices 300a and 300b are communicably connected to the policy management devices 100a and 100b, respectively.

  FIG. 12 is a sequence diagram showing an example of a processing flow in the policy control system of FIG. The processing from step S101 to step S110 is the same as the processing shown in FIG. The policy management apparatus 100a periodically transmits / receives a state matching command (Subscription-ID: A, B, C, D, E) to / from the policy management apparatus 100b (step S301).

  For example, assume that the policy management apparatus 100a fails and is switched to the policy management apparatus 100b (step S302). In the prior art, when switching occurs, for example, the packet header identification control devices 200a and 200b transmit a CCR message requesting a policy to the policy management device 100b. On the other hand, according to the policy control system 1D of the fourth embodiment, even if the policy management apparatus 100 is switched, the call information processed by the policy management apparatus 100a is transferred to the policy management apparatus 100b by the state matching command. Therefore, for example, the packet header identification control devices 200a and 200b do not need to request a policy from the policy management device 100b.

  Further, as a redundancy method of the policy management device 100, in the case where the config setting is made redundant, in the conventional method, by changing the origin state ID indicating the information on the number of server activations, the policy management device 100 The CCR-I messages for all sessions of all subordinate apparatuses are transmitted to the policy management apparatus 100, and the policy management apparatus 100 performs these processes and returns a CCA message, which places a heavy burden on the policy management apparatus 100. . On the other hand, according to the policy control system 1D of the fourth embodiment, state matching is periodically performed between the policy management apparatuses 100a and 100b, and the origin state ID is changed when the policy management apparatus 100 is switched. The processing can be continued without any problem.

(Fifth embodiment)
FIG. 13 is a block diagram schematically showing the configuration of the policy control system according to the fifth embodiment of the present invention. As shown in FIG. 13, the policy control system 1E is different from the policy control system 1D (see FIG. 11) in that it includes a plurality of redundant routing devices 500a and 500b. Here, the routing device 500a is an active device, that is, an active device (ACT). The routing device 500b is a spare device, that is, a standby device (SBY). The routing devices 500a and 500b are connected so as to communicate with each other. In the following description, the routing device 500 is used unless otherwise specified.

  The routing device 500 determines a correspondence relationship between the packet header identification control device 200, the application identification device 300, and the policy management device 100, and performs routing of signals transmitted / received to / from each other. The routing device 500 corresponds to a DRA device (Diameter Routing Agent) defined by 3GPP, and distributes processing according to resources of a plurality of policy management devices 100a and 100b. Since DRA is described in Non-Patent Document 1, description thereof is omitted.

FIG. 14 is a sequence diagram showing an example of a process flow in the policy control system of FIG. The processing from step S101 to step S104 is the same as the processing shown in FIG. Further, the processing in step S301 is the same as the processing shown in FIG.
The routing device 500a periodically transmits a state matching command (Subscription-ID: A, B, C, D, E) to the routing device 500b (step S401).

  For example, assume that the packet header identification control device 200a detects a trigger such as a failure of the application identification device 300b, for example (step S402). In this case, the packet header identification control device 200a transmits to the routing device 500a a CCR message requesting re-stretching for the session currently connected to the application identification device 300b (step S403). The routing device 500a transfers the CCR message to the policy management device 100a (step S404).

  Then, the policy management apparatus 100a determines another application identification apparatus 300a and transmits a TSR message requesting addition of a session addressed to the application identification apparatus 300a to the routing apparatus 500a (step S405). Then, the routing device 500a transfers the TSR message to the application identification device 300a (step S406).

  Then, the application identification device 300a returns a TSA message in response to the request to the routing device 500a (step S407). Then, the routing device 500a transfers the TSA message to the policy management device 100a (step S408). Then, the policy management apparatus 100a transmits to the routing apparatus 500a a CCA message that responds to the packet header identification control apparatus 200a that has requested re-establishment of the session (step S409). Then, the routing device 500a transfers the CCA message to the packet header identification control device 200a (step S410).

  The routing device 500 basically has a 1: 1 redundancy configuration and needs to take over the state. According to the policy control system 1E of the fifth embodiment, the state matching command can be used to take over the state possessed by each device in the routing devices 500a and 500b configured in a 1: 1 redundancy configuration. As described above, by periodically transmitting the state matching command from the routing device 500a as the active device to the routing device 500b as the standby device, a redundant configuration that does not affect the call can be realized.

(Sixth embodiment)
FIG. 15 is a block diagram schematically showing the configuration of the policy control system according to the sixth embodiment of the present invention. As shown in FIG. 15, the policy control system 1F is different from the policy control system 1E (see FIG. 13) in that it includes a plurality of sorting apparatuses 400a and 400b.

FIG. 16 is a sequence diagram illustrating an example of a process flow in the policy control system of FIG. The processing from step S101 to step S104 is the same as the processing shown in FIG. Further, the process of step S301 is the same as the process shown in FIG. 12, and the process of step S401 is the same as the process shown in FIG.
The routing device 500a periodically transmits / receives a state matching command (Subscription-ID: A, B, C, D, E) to / from the distribution device 400a (step S501).

  Under the above assumption, for example, the packet header identification control device 200a detects a trigger such as an external distribution request signal (step S502). In this case, the packet header identification control device 200a transmits a CCR message requesting flow distribution to the routing device 500a (step S503). Then, the routing device 500a selects and determines the policy management device 100a, and transfers the CCR message to the policy management device 100a (step S504).

  Then, the policy management apparatus 100a returns, to the routing apparatus 500a, a TSR message addressed to the application identification apparatus 300a that distributes a session whose Subscription-ID is “A, B”, for example (step S505). Accordingly, the routing device 500a can recognize the application identification device 300a that is the distribution destination. Then, the routing device 500a transfers the TSR message to the application identification device 300a (step S506).

  Then, the application identification device 300a returns a TSA message in response to the request to the routing device 500a (step S507). Then, the routing device 500a transfers the TSA message to the policy management device 100a (step S508). Similarly, although not shown, the policy management apparatus 100a transmits, to the routing apparatus 500a, a TSR message addressed to the application identification apparatus 300b that distributes sessions having Subscription-IDs “C, D, E”, for example.

  Then, the routing device 500a includes a list including a plurality of key information for grouping flows and information of the application identification device 300 assigned by the key information in the state matching command, and includes the state matching command (300a = Subscription -ID = A, B, 300b = Subscription-ID = C, D, E) is transmitted to the sorting apparatus 400a (step S509). Thereby, the distribution apparatus 400a can distribute a flow according to the set policy.

  Then, the policy management device 100a transmits to the routing device 500a a CCA message that responds to the packet header identification control device 200a that requested the flow distribution (step S510). Then, the routing device 500a transfers the CCA message to the packet header identification control device 200a (step S511).

  According to the policy control system 1F of the sixth embodiment, the application identification device 300 is determined by an instruction from the policy management device 100a selected by the routing device 500a. Then, in the routing device 500a, the distributed application identification device 300 is identified. Therefore, by matching the state between the routing device 500a and the distribution device 400a, the application identification device 300 can be scaled out while enabling distribution.

  As mentioned above, although each embodiment of this invention was described, this invention is not limited to these, It can implement in the range which does not change the meaning. For example, in the present embodiment, the PCC rule and the ADC rule as a policy have been described as eliminating the state mismatch between the devices. However, the present invention is not limited to this, and statistical information regarding packets for service charging control or flow control is used. Also, it is possible to resolve the state mismatch between the devices. Here, the statistical information regarding the packet is, for example, packet count information, which can be used for billing. By doing in this way, even if statistical information is lost in any one of the policy management apparatus 100, the packet header identification control apparatus 200, and the application identification apparatus 300, the remaining statistical information is used as a basis. Stats can be continued and billed as accurately as possible. When the policy management apparatus 100 fails, the statistical information may be matched with the statistical information held by the packet header identification control apparatus 200 or the application identification apparatus 300.

  In the above embodiment, the policy management device 100 or the like terminates the process when there is no difference between the key information list extracted from the received state matching command and the information held by the own device (step S12: No). However, the present invention is not limited to this, and the transmission source of the state matching command may be notified that there is no difference. By doing so, it is possible to prevent the transmission source of the state matching command from misidentifying that the transmission destination is out of order.

  Further, for example, the policy management apparatus 100, the packet header identification control apparatus 200, and the application identification apparatus 300 of the policy control system 1 can be realized by dedicated servers, respectively, and a general computer is connected to the policy management apparatus 100, It can also be realized by operating with a program that functions as the packet header identification control device 200 and the application identification device 300. These programs can be provided via a communication line, or can be written on a recording medium such as a CD-ROM and distributed.

1, 1B, 1C, 1D, 1E, 1F Policy control system 2 IP network 100, 100a, 100b Policy management device 200, 200a, 200b Packet header identification control device 300, 300a, 300b Application identification device 400a, 400b Distribution device 500a Routing device (ACT)
500b Routing device (SBY)
700 gateway 810 subscriber database 820 online charging system 830 offline charging system 840 access network gateway 850 application server

Claims (8)

A policy management device that sets a policy for a service for a predetermined device connected to be communicable with each other;
An application identification device that identifies a data portion of a packet that constitutes a flow as the predetermined device according to a policy of a set service;
A packet header identification control device for transferring a flow that matches the policy of the set service in the predetermined device to the application identification device;
A policy control system comprising a plurality of devices including:
The policy management device obtains the status information of the policy of the service held in the counter device from the counter device which is one of the predetermined devices at least at one timing periodically and at the time of recovery from the failure. When the status matching command is received, and when the difference is detected by comparing the status information extracted from the received status matching command with the status information including the policy of the service held by the own device, it is held by the opposite device A policy control system characterized in that information corresponding to the detected difference is added to or deleted from the opposite device among the policy policy status information. A policy management device that sets a policy for a service for a predetermined device connected to be communicable with each other;
An application identification device that identifies a data portion of a packet that constitutes a flow as the predetermined device according to a policy of a set service;
A packet header identification control device for transferring a flow that matches the policy of the set service in the predetermined device to the application identification device;
A policy control system comprising a plurality of devices including:
The packet header identification control device periodically and at least at one of the timings of recovery from a failure, state matching including status information of the policy of the service held by the policy management device from the policy management device If a difference is detected by receiving a command and comparing the status information extracted from the received status matching command with the status information including the policy of the service held by the own device, the policy of the service held by the own device A policy control system characterized in that information corresponding to the detected difference is added or deleted from the state information. At least one policy management device;
A plurality of the packet header identification control devices;
A policy control system comprising a plurality of said application identification devices,
The state matching command transmitted and received between the devices further includes statistical information on a packet for charging control or flow control of the service,
The two devices of the set consisting of the packet header identification control device and the application identification device connected so as to be communicable with each other periodically transmit / receive the state matching command held by the own device, and the devices held by each device Match service policy status information and statistics,
If one device in the two devices in the set does not receive the state matching command from the other device even after a predetermined time has elapsed, the device and the other device are instructed to the policy management device. 3. The policy control system according to claim 1, wherein the connection is requested to be switched to a connection between the own device and another device that has not failed. A policy control system in which a plurality of the packet header identification control devices share a plurality of the application identification devices with each other,
The packet header identification control device and the application identification device include a list including a plurality of key information for grouping the flows in the state matching command for each combination of the application identification device and the packet header identification control device. The policy control system according to claim 3, wherein the state matching command is periodically transmitted and received. A policy control system further comprising a plurality of distribution devices that distribute the flow from each packet header identification control device to each of the plurality of application identification devices,
Triggered by a predetermined signal received from the outside by the packet header identification control device, the policy management device matches the application identification device and the packet header identification control device with the state matching command. Including a list including a plurality of key information for grouping and information of the application identification device assigned by the key information in the state matching command, and transmitting the state matching command to the distribution device.
The policy control system according to claim 4. A policy control system comprising a plurality of the policy management devices made redundant so as to be switchable,
The redundant policy management devices include a plurality of key information for grouping the flows that are matched by the state matching command between the application identification device and the packet header identification control device. Is included in the state matching command, and the state matching command is periodically transmitted and received.
The policy control system according to claim 4. A policy control system comprising a plurality of redundant routing devices that distribute processing according to resources of the plurality of redundant policy management devices,
The current routing device uses, as the state matching command, a list including a plurality of key information for grouping the flows that are matched by the state matching command between the application identification device and the packet header identification control device. The policy control system according to claim 6, wherein the state matching command is periodically transmitted to the spare routing device.   A program for causing a computer to function as the policy management apparatus provided in the policy control system according to claim 1 or the packet header identification control apparatus provided in the policy control system according to claim 2.

Images