Methods, systems, and computer readable media for providing access network session correlation for policy control

Abstract

A method for access network session correlation for policy control includes detecting a remote authentication dial in user service (RADIUS) access session for a user device, including binding the RADIUS access session to a policy node. The method includes detecting a Diameter session for the user device. The method further includes correlating the RADIUS access session with the Diameter session, including binding the Diameter session to the policy node.

Description

TECHNICAL FIELD

The subject matter described herein relates to access network protocols for authentication, authorization, and accounting on computer networks for policy control.

BACKGROUND

Mobile communications devices and subscribers typically have two or more modes for accessing network services. For example, current mobile communications devices and subscribers may be capable of accessing a cellular network (e.g., a long term evolution (LTE), 3G network, or wireless local area network (LAN)) and a fixed network, e.g., a digital subscriber line (DSL) or cable network. As mobile operators deploy and/or integrate fixed networks into their service solutions, those mobile operators will seek to integrate policy control with those fixed networks. Some fixed networks use the remote authentication dial-in user service (RADIUS) protocol for authentication, authorization, and accounting. RADIUS-based access networks can use the RADIUS Change-of-Authorization (CoA) message to apply policy from a policy server to a RADIUS client. The 3^rd Generation Partnership Project (3GPP) has defined Diameter-based interfaces for policy control.

Accordingly, there exists a need for methods, systems, and computer readable media for providing access network session correlation for policy control in systems that integrate fixed networks and mobile networks.

SUMMARY

The subject matter described herein includes methods, systems, and computer readable media for providing access network session correlation for policy control, e.g., between a RADIUS access network session and a core network Diameter session. A method for access network session correlation for policy control includes detecting a remote authentication dial in user service (RADIUS) access session for a user device, including binding the RADIUS access session to a policy node. The method includes detecting a Diameter session for the user device. The method further includes correlating the RADIUS access session with the Diameter session, including binding the Diameter session to the policy node.

The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms “function” “node” or “module” as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a network diagram illustrating a Diameter signaling router (DSR) that performs multi-protocol session correlation;

FIG. 2 is a block diagram of an example architecture for a DSR;

FIG. 3 is a message diagram illustrating an example RADIUS access session initiation message flow;

FIG. 4 is a message diagram illustrating an example message flow of policy installation or removal on an established RADIUS access session;

FIG. 5 is a message diagram illustrating an example message flow in which a RADIUS access session is correlated to a Diameter session;

FIG. 6 is a message diagram illustrating an example RADIUS session termination message flow;

FIG. 7 is a message diagram illustrating an example message flow for session termination by a PCRF-initiated disconnect;

FIG. 8 is a network diagram of an example network for RADIUS access session accounting and policy support; and

FIG. 9 is a flow diagram of an example method for providing multi-protocol session correlation for policy control.

DETAILED DESCRIPTION

The subject matter described herein includes methods, systems, computer readable media for providing access network session correlation for policy control. FIG. 1 is a network diagram illustrating an example Diameter signaling router (DSR) that performs multi-protocol session correlation. Referring to FIG. 1, an example network 100 includes a DSR 102 that performs the steps described herein for correlating a RADIUS access session, e.g., a session originating from a fixed network such as a Wi-Fi network, with a Diameter session. For example, the Diameter session can be an access session or an application session originating from an application server.

DSR 102 can be implemented as a system of one or more computers executing software for routing Diameter and RADIUS messages. For example, DSR 102 may be implemented on a computing platform that includes one or more processor blades, each implementing a routing agent or other function. DSR 102 may be implemented in a distributed computing system or any appropriate system of one or more computers.

RADIUS is a networking protocol that provides authentication, authorization, and accounting management for users of a network. RADIUS is a client/server protocol that typically runs in the application layer using the user datagram protocol (UDP) for transport. Diameter is a networking protocol that evolved from RADIUS for authentication, authorization, and accounting. Diameter applications extend the base protocol by adding new commands and/or attributes, e.g., commands and attributes for use in policy and charging control. A typical Diameter packet includes a Diameter header and a variable number of attribute-value pairs (AVPs) for encapsulating information relevant to the Diameter message.

DSR 102 is configured to route both Diameter messages and RADIUS messages to policy and charging rules function (PCRF) 104. PCRF 104 can be implemented as one or more computer systems each configured to operate as a policy node for network 100. PCRF 104 is part of a 3GPP policy charging control (PCC) architecture. The elements of the PCC provide access, resource, and quality-of-service (QoS) control.

In operation, PCRF 104 functions in real-time or near real-time to determine policy rules in network 100. PCRF 104 can operate at the network core and access user information and other specialized functions in a centralized manner. PCRF 104 can aggregate information to and from network 100, operational support systems, and other sources in real time, which can be useful for the creation of rules and automatically making policy decisions for each user active on network 100. Using PCRF 104, network 100 can offer multiple services, QoS levels, and charging rules. PCRF 104 is configured to support both RADIUS and Diameter.

DSR 102 interfaces with broadband network gateway (BNG) 106 using RADIUS. BNG 106 routes network traffic to and from broadband remote access devices. User device 108 may connect to BNG 106 using, e.g., a Wi-Fi access point, a digital subscriber line (DSL) or cable modem, or any appropriate network connection.

Network 100 includes an application function (AF) 110. AF 110 can be implemented as a system of one or more computers. AF 110 communicates with PCRF 104 over a Diameter Rx interface. AF 110 can interact with applications or services that require dynamic PCC. AF 110 can extract session information from an application signal and provide the extracted information to PCRF 104.

Network 100 includes a traffic detection function (TDF) 112. TDF 112 can be implemented as a system of one or more computers. PCRF 104 communicates with TDF 112 using a Diameter Sd or other Diameter interface. TDF 112 can enforce traffic policies based on pre-set rules or dynamically determining rules by PCRF 104 on data flows in real-time or near real-time.

In some examples, DSR 102 can be implemented as a number of Diameter routing agents (DRAs) that are configured, by virtue of appropriate programming and network configuration, to collectively operative as a single routing agent. For example, DSR 102 can maintain state information (e.g., information that associates a subscriber or session with a particular server) for Diameter sessions within network 100.

The DRAs may each include a database for binding access sessions to policy nodes by maintaining associations between access sessions and policy nodes within network 100. The databases can be synchronized using one or more of any appropriate database coherency techniques, e.g., replication techniques or message-based techniques. Subscribers can be identified using any appropriate identifier, e.g., an international mobile subscriber identity (IMSI), an Internet protocol (IP) address, or a unique subscriber identifier.

To provide policy to a subscriber on a fixed network, DSR 102 can bind a RADIUS access session to a Diameter session, e.g., using the same techniques used to bind one Diameter session to another Diameter session. This can be useful, e.g., for a converged carrier to use the same policy node for both fixed and mobile connections, even if the fixed network uses RADIUS. Since DSR 102 includes software that supports stateful session binding and correlation for Diameter policy sessions, the same software and stateful database(s) can be used to bind a RADIUS access session to a policy node and potentially to one or more Diameter sessions.

FIG. 2 is a block diagram of an example architecture for DSR 102. DSR 102 includes one or more processors 202 and memory 204 for storing executable instructions for processors 202 and other data. For example, DSR 102 can be implemented using one or more message processors, each of which can be implemented as a printed circuit board or blade that includes at least one processor and memory. Executable instructions can be loaded into random access memory (RAM) for execution by the processors 202.

DSR 102 includes a RADIUS connection layer (RCL) 206 including a RADIUS handler 208 and a Diameter encapsulation/decapsulation module 210. The RADIUS handler 208 receives and sends UDP messages for a RADIUS session. The Diameter encapsulation/decapsulation module 210 encapsulates received RADIUS messages into a Diameter shell and un-encapsulates outbound Diameter messages into RADIUS messages.

RCL 206 routes incoming messages to a Diameter routing layer (DRL) 212. DRL 212 can include an application routing table (ART) that DRL 212 uses to trigger a policy and charging application (PCA) 214 for a message. PCA 214 generates a response and DRL 212 routes the response message received from PCA 214 to RCL 206. RCL 206 then un-encapsulates the message and sends the message out. In some examples, RCL 206 is configured to drop error messages generated by PCA 214 or DRL 212.

PCA 214 is configured to bind and correlate Diameter sessions using a stateful database 218. When PCA 214 binds a Diameter session to a policy node, PCA 214 stores in stateful database 218 an association between the Diameter session and an identifier of the policy node so that network traffic for that Diameter session can be routed to that policy node. When PCA 214 correlates another Diameter session to the Diameter session, PCA 214 stores in stateful database 218 an association between the two Diameter sessions so that network traffic for both Diameter sessions can be routed to the same policy node.

PCA 214 can bind a RADIUS access session to a Diameter session by virtue of RCL 206, which encapsulates and un-encapsulates RADIUS messages. In this manner, PCA 214 treats a RADIUS access session as a binding-capable access session by treating it like a Diameter session. Although FIG. 2 illustrates RCL 206 as encapsulating and un-encapsulating RADIUS messages, other architectures are possible; for example, PCA 214 can be configured to handle RADIUS access sessions directly, so that the Diameter encapsulation/decapsulation module 210 may not be necessary.

The architecture illustrated in FIG. 2 is a special purpose machine that performs access network session correlation for policy control. The architecture illustrated in FIG. 2 improves the functionality of both access and cellular networks by binding RADIUS sessions to policy nodes and correlating RADIUS access sessions with Diameter sessions, e.g., Diameter sessions that are established for a user device after a RADIUS access session is established for that user device. The software infrastructure for binding and correlating Diameter sessions can be used for binding and correlating a RADIUS access session to a Diameter session. Binding and correlating a RADIUS access session to a Diameter session can be useful to a mobile operator deploying or integrating fixed networks with a mobile network for policy control because many fixed networks use RADIUS.

FIG. 3 is a message diagram illustrating an example RADIUS access session initiation message flow 300. BNG 106 initiates message flow 300 by sending an Accounting-Start message 302 to DSR 102. Accounting-Start message 302 can include the following attribute/value pairs:

• • Acct-Session-ID
  • Framed-IP-Address or IPv6-Prefix
  • NAS-Identifier or NAS-IP(v6)-Address

RCL 206 receives Accounting-Start message 302 and encapsulates Accounting-Start message 302 into a Credit-Control-Request (CCR-I) message 304. CCR-I message 304 can include the following attribute/value pairs:

• • Auth-Application-ID=Ra
  • Origin-Host=BNG
  • Session-ID
  • Framed-IP-Address or IPv6-Prefix

A new Diameter Application-ID (‘Ra’) is used to distinguish RADIUS sessions that are encapsulated in Diameter messages. RCL 206 sends CCR-I message 304 to PCA 214. Table 1 illustrates example values for attributes of CCR-I message 304.

TABLE 1
Internal Diameter
message           Value
Session-ID        Set to value of RADIUS Acct-Session-ID (if present),
                  prefixed by client FQDN, for CCR-I/U/T. Set to 0 for
                  CCR-E.
Auth-Application- Set to value configured for incoming connection -
ID                new value, e.g., ‘Ra’
Command-Code      CCR
CC-Request-Type   Initial, Update, Termination, or Event
Framed-IP-        Straight mapping from RADIUS Framed-IP-Address
Address or        or Framed-IPvG-Prefix
Framed-IPv6-
Prefix

PCA 214 binds to PCRF 104 by creating a session binding record using a modified Acct-Session-ID as Session-ID. The Framed-IP-Address or IPv6-Prefix, if present, is stored in the session binding record. APN can be set to ‘RADIUS’ for Ra sessions by PCA 214.

PCA 214 generates a CCR-I message 306 that is modified from CCR-I message 304. CCR-I message 306 includes a pointer to a specific peer routing table (PRT) to use for CCR-I message 306. CCR-I message 306 also includes a Destination-Host value for CCR-U/T/E. CCR-I message 306 can include the following attribute/value pairs:

• • Auth-Application-ID=Ra
  • Origin-Host=BNG
  • Destination-Host=PCRF

PCA 214 sends CCR-I message 306 to RCL 206. RCL 206 un-encapsulates CCR-I message 306 and sends message 308 from DSR 102 to PCRF 104. Message 308 is the same as message 302 and is routed to PCRF 104 based on PCA 214.

PCRF 104 responds by generating an Accounting-Response message 310. PCRF 104 sends Accounting-Response message 310 to DSR 102. RCL 206 receives Accounting-Response message 310 and encapsulates Accounting-Response message 310 into a Credit-Control-Answer (CCA-I) message 312. CCA-I message 312 can include the following attribute/value pairs:

• • Origin-Host=PCRF
  • Session-ID

Table 2 illustrates example values for attributes of CCA-I message 312.

TABLE 2
Internal Diameter
message           Value
Command-Code      CCA
CC-Request-Type   Initial, Update, Termination, or Event
Session-ID        Same value as corresponding Diameter
                  Request
Origin-Realm/Host Use value configured for ingress peer
                  (PCRF/AAA)

RCL 206 sends CCA-I message 312 to PCA 214. PCA 214 processes CCA-I message 312 and sends a message 314 to RCL 206. Message 314 is the same as CCA-I message 312. RCL 206 receives message 314 and un-encapsulates message 314 to generate message 316. Message 316 is the same as Accounting-Response message 310. DSR 102 sends message 316 to BNG 106.

FIG. 4 is a message diagram illustrating an example message flow 400 of policy installation or removal on an established RADIUS access session. PCRF 104 initiates message flow 300 by sending a CoA-Request message 402 to DSR 102. CoA-Request message 402 can include the following attribute/value pairs:

• • NAS-Identifier or NAS-IP(v6)-Address
  • Acct-Session-ID
  • VAS rule set

RCL 206 receives CoA-Request message 402 and encapsulates CoA-Request message 402 into a Re-Auth-Request (RAR) message 404. RAR message 404 can include the following attribute/value pairs:

• • Auth-Application-I D=Ra
  • Origin-Host=PCRF
  • Destination-Host=BNG
  • Session-ID

Table 3 illustrates example values for attributes of RAR message 404.

TABLE 3
Internal Diameter
message              Value
Session-ID           Set to value of RADIUS Acct-Session-ID,
                     prefixed by NAS FQDN
Auth-Application-ID  Set to value configured for incoming connection
                     e.g., new value ‘Ra’
Command-Code         RAR
Framed-IP-Address or Straight mapping from RADIUS Framed-IP-
Framed-IPv6-Prefix   Address or Framed-IPv6-Prefix

RCL 206 sends RAR message 404 to PCA 214. PCA 214 can use RAR message 404 to update a session timer for the RADIUS access session. PCA 214 can be configured to maintain user-configurable session timers per Access Point Name (APN). PCA 214 can create an APN for the RADIUS access session, and then PCA 214 can maintain the session timer for the RADIUS access session and update the session timer each time a message is processed for that session. In response to detecting a session timeout, PCA 214 can delete a session and the bindings associated with the session. The Acct-Session-ID value can be used as the Session-ID value in the session binding record.

PCA 214 sends a message 406 back to RCL 206. Message 406 is the same as RAR message 404. RCL 206 un-encapsulates message 406 to generate a message 408. Message 408 is the same as CoA-Request message 402. RCL 206 sends message 408 to BNG 106.

BNG 106 generates a CoA-ACK/NAK message 410 and sends CoA-ACK/NAK message 410 to DRL 102. RCL 206 receives CoA-ACK/NAK message 410 and encapsulates CoA-ACK/NAK message 410 into a Re-Auth-Answer (RAA) message 412. RAA message 412 can include the following attribute/value pairs:

• • Origin-Host=BNG
  • Session-ID

Table 4 illustrates example values for attributes of RAA message 412.

TABLE 4
Internal Diameter
message           Value
Command-Code      RAA
Session-ID        Same value as corresponding Diameter
                  Request
Origin-Realm/Host Use value configured for ingress peer

RAA message 412 can include these values regardless of whether a CoA-ACK or CoA-NAK was received. RCL 206 sends RAA message 412 to PCA 214. PCA 214 processes RAA message 412 and sends a message 414 back to RCL 206. Message 414 is the same as RAA message 412.

RCL 206 un-encapsulates message 414 and generates CoA-ACK/NAK message 416. CoA-ACK/NAK message 416 is the same as CoA-ACK/NAK message 410. RCL 206 sends CoA-ACK/NAK message 416 to PCRF 104.

FIG. 5 is a message diagram illustrating an example message flow 500 in which a RADIUS access session is correlated to a Diameter session. AF 110 initiates message flow 500 by sending an AA-Request (AAR) message 502 to DSR 102. AAR message 502 can include the following attribute/value pairs:

• • Session-ID
  • Framed-IP-Address/IPv6-Prefix

DSR 102 routes the AAR message 502 to PCRF 104 by sending a message 504 to PCRF 104. Message 504 is the same as AAR message 502. PCRF 104 responds by sending an AA-Answer (AAA) message 506 to DSR 102. DSR 102 routes the AAA message 506 to AF 110 by sending a message 508 to AF 110. Message 508 is the same as AAA message 506. Message flow 500 establishes an Rx session for AF 110 and PCRF 104.

DSR 102 can determine that the Rx session is associated with a same user device as the RADIUS access session established, e.g., by message flow 300 in FIG. 3. For example, DSR 102 can determine that both sessions share the same IP address, i.e., have the same Framed-IP-Address/IPv6-Prefix value. In response to determining that both sessions are associated with the same user device, DSR 102 binds the Rx session to the same PCRF 104 and correlates the Rx session with the RADIUS session so that a mobile operator can apply policy controls to both sessions using the same policy node.

FIG. 6 is a message diagram illustrating an example RADIUS session termination message flow 600. In some examples, message flow 600 is triggered by a CoA message from PCRF 104 that removes services from BNG 106. BNG 106 initiates message flow 600 by sending an Accounting-Stop message 602 to DSR 102. Accounting-Stop message 602 can include the following attribute/value pairs:

• • Acct-Session-ID
  • NAS-Identifier or NAS-IP(v6)-Address

RCL 206 receives Accounting-Stop message 602 and encapsulates Accounting-Stop message 602 into a Credit-Control-Request (CCR-T) message 604. CCR-T message 604 can include the following attribute/value pairs:

• • Auth-Application-ID=Ra
  • Origin-Host=BNG
  • Session-ID

RCL 206 sends CCR-T message 604 to PCA 214. PCA 214 generates a CCR-T message 606 that is modified from CCR-T message 604. CCR-T message 604 can include the following attribute/value pairs:

• • Auth-Application-ID=Ra
  • Origin-Host=BNG
  • Destination-Host=PCRF

PCA sends CCR-T message 606 to RCL 206. RCL 206 un-encapsulates CCR-T message 606 and sends message 608 from DSR 102 to PCRF 104. Message 608 is the same as Accounting-Stop message 602 and is routed to PCRF 104 based on PCA 214.

PCRF 104 responds by generating an Accounting-Response message 610. PCRF 104 sends Accounting-Response message 610 to DSR 102. RCL 206 receives Accounting-Response message 610 and encapsulates Accounting-Response message 610 into a Credit-Control-Answer (CCA-T) message 612. CCA-T message 612 can include the following attribute/value pairs:

• • Origin-Host=PCRF
  • Session-ID

RCL 206 sends CCA-T message 612 to PCA 214. PCA 214 processes CCA-T message 612 by deleting the RADIUS access session and all associated binding information in response to receiving CCA-T message 612. PCA sends a message 614 to RCL 206. Message 614 is the same as CCA-T message 612. RCL 206 receives message 614 and un-encapsulates message 614 to generate message 616. Message 616 is the same as Accounting-Response message 610. DSR 102 sends message 616 to BNG 106.

FIG. 7 is a message diagram illustrating an example message flow 700 for session termination by a PCRF-initiated disconnect. PCRF 104 initiates message flow 700 by sending a Disconnect-Request message 702 to DSR 102. Disconnect-Request message 702 can include the following attribute/value pairs:

• • NAS-Identifier or NAS-IP(v6)-Address
  • Acct-Session-ID

RCL 206 receives Disconnect-Request message 702 and encapsulates Disconnect-Request message 702 into a RADIA-Request (RDR) message 704. RDR message 704 can include the following attribute/value pairs:

• • Auth-Application-ID=Ra
  • Origin-Host=PCRF
  • Destination-Host=BNG
  • Session-ID

RCL 206 sends RDR message 704 to PCA 214. PCA 214 deletes the RADIUS session in response to receiving RDR message 704. PCA 214 sends a message 706 back to RCL 206. Message 706 is the same as RDR message 704. RCL 206 un-encapsulates message 706 to generate a message 708. Message 708 is the same as Disconnect-Request message 702. RCL 206 sends message 708 to BNG 106.

BNG 106 generates a Disconnect-ACK/NAK message 710 and sends Disconnect-ACK/NAK message 710 to DRL 102. RCL 206 receives Disconnect-ACK/NAK message 710 and encapsulates Disconnect-ACK/NAK message 710 into a RADIA-Answer (RDA) message 712. RDA message 712 can include the following attribute/value pairs:

• • Origin-Host=BNG
  • Session-ID

RCL 206 sends RDA message 712 to PCA 214. PCA 214 processes RDA message 712 and sends a message 714 back to RCL 206. Message 714 is the same as RDA message 712.

RCL 206 un-encapsulates message 714 and generates Disconnect-ACK/NAK message 716. Disconnect-ACK/NAK message 716 is the same as Disconnect-ACK/NAK message 710. RCL 206 sends Disconnect-ACK/NAK message 710 to PCRF 104. If BNG 106 sends an Accounting-Stop message after PCA 214 processes RDR message 704, the session will not be found by PCA 214.

FIG. 8 is a network diagram of an example network 800 for RADIUS access session accounting and policy support. In example network 800, DSR 102 can be configured to use, e.g., PCA 214 of FIG. 2, to provide stateful, session-based routing for policy from PCRF nodes 802. The routing for policy can be supported by the same DSR 102. PCA PCRF sub-pooling can be used to separate network traffic for messages originating at different BNGs, e.g., for messages originating from BNG1806 and BNG2808.

FIG. 9 is a flow diagram of an example method 900 for providing multi-protocol session correlation for policy control. The method 900 is performed by a DSR including at least one message processor, e.g., DSR 102 of FIG. 1 and FIG. 2.

The DSR detects a RADIUS access session for a user device (902). For example, detecting the RADIUS access session can include receiving a request message from an access gateway, routing the request message to a policy charging and rules function (PCRF), and routing a response message from the PCRF to the access gateway to establish a fixed network connection for the user device. The access gateway can be, e.g., a broadband network gateway (BNG) or a WLAN access gateway (WAG). Other examples of access gateways include packet data network gateways (PGWs) and GPRS support nodes (GGSNs).

The DSR binds the RADIUS access session to a policy node (904) Binding the RADIUS session can include storing RADIUS session information for the RADIUS access session in a stateful session database. The RADIUS session information can be, e.g., an Acct-Session-ID value and an Internet protocol (IP) address or subscriber identifier from a RADIUS Accounting-Request message. In some examples, detecting the RADIUS access session includes maintaining a session timer for the RADIUS access session, updating the session timer each time a message is processed for the RADIUS access session, and, in response to detecting a session timeout using the session timer, deleting the RADIUS access session and any bindings for the RADIUS access session.

In some examples, detecting the RADIUS access session includes receiving a RADIUS request message, translating the RADIUS request message into a Diameter request message, determining routing information for the RADIUS request message using the Diameter request message, and routing the RADIUS request message using the routing information. The RADIUS request message can be an Accounting-Start message and the Diameter request message can be a Credit-Control-Request (CCR) message.

The DSR detects a Diameter session for the user device (906). The Diameter session can be, e.g., an access session or an application session. For example, detecting the Diameter session can include receiving a request message from an application function (AF) or a traffic detection function (TDF) routing the request message to a policy charging and rules function (PCRF) and routing a response message from the PCRF to the AF or TDF. Although FIG. 9 illustrates detecting the RADIUS access session before the Diameter session, in some cases, the DSR will detect the Diameter session before detecting the RADIUS session. In those cases, the DSR can still correlate the RADIUS access session to the Diameter session.

The DSR correlates the RADIUS access session to the Diameter session, including binding the Diameter session to the policy node (908). For example, correlating the RADIUS session with the Diameter session can include comparing Diameter session information for the Diameter session with the RADIUS session information and determining that the Diameter session corresponds to the user device of the RADIUS session. The DSR can receive a Change-of-Authorization (CoA) command from the policy node and route the CoA command for policy installation and/or removal for the RADIUS access session.

Accordingly, while the methods, systems, and computer readable media have been described herein in reference to specific embodiments, features, and illustrative embodiments, it will be appreciated that the utility of the subject matter is not thus limited, but rather extends to and encompasses numerous other variations, modifications and alternative embodiments, as will suggest themselves to those of ordinary skill in the field of the present subject matter, based on the disclosure herein.

Various combinations and sub-combinations of the structures and features described herein are contemplated and will be apparent to a skilled person having knowledge of this disclosure. Any of the various features and elements as disclosed herein may be combined with one or more other disclosed features and elements unless indicated to the contrary herein.

Correspondingly, the subject matter as hereinafter claimed is intended to be broadly construed and interpreted, as including all such variations, modifications and alternative embodiments, within its scope and including equivalents of the claims. It is understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.

Claims

1. A method for access network session correlation for policy control, the method comprising: in a Diameter signaling router (DSR) including at least one message processor: detecting a remote authentication dial in user service (RADIUS) access session for a user device, including identifying a policy node from a plurality of policy nodes and binding the RADIUS access session to the policy node and routing RADIUS messages for the RADIUS access session from the DSR to the policy node, wherein detecting the RADIUS access session comprises receiving a request message from an access gateway, routing the request message to a policy and charging rules function (PCRF) configured to receive and process both RADIUS and Diameter messages and to provide one or more policy services for both RADIUS and Diameter access sessions, and routing a response message from the PCRF to the access gateway to establish a fixed network connection for the user device;detecting a Diameter session for the user device;correlating the RADIUS access session with the Diameter session, including binding the Diameter session to the policy node in response to determining that the Diameter session corresponds to the RADIUS access session and routing Diameter messages for the Diameter session from the DSR to the policy node; andafter correlating the RADIUS access session with the Diameter session, routing both the RADIUS messages for the RADIUS access session for the user device to the policy node and the Diameter messages for the RADIUS access session for the same user device to the policy node.

2. The method of claim 1, wherein detecting the Diameter session comprises receiving a request message from an application function (AF) or a traffic detection function (TDF) or the access gateway, routing the request message to the PCRF, and routing a response message from the PCRF to the AF or TDF or access gateway.

3. The method of claim 1, wherein detecting the RADIUS access session comprises storing RADIUS session information for the RADIUS access session in a stateful session database.

4. The method of claim 3, wherein correlating the RADIUS access session with the Diameter session comprises comparing Diameter session information for the Diameter session with the RADIUS session information.

5. The method of claim 3, wherein storing RADIUS session information comprises storing an Acct-Session-ID value and an Internet protocol (IP) address or subscriber identifier from a RADIUS Accounting-Request message.

6. The method of claim 1, wherein detecting the RADIUS access session comprises maintaining a session timer for the RADIUS access session, updating the session timer each time a message is processed for the RADIUS access session, and, in response to detecting a session timeout using the session timer, deleting the RADIUS access session and any bindings for the RADIUS access session.

7. The method of claim 1, comprising receiving a Change-of-Authorization (CoA) command from the policy node and routing the CoA command for policy installation and/or removal for the RADIUS access session.

8. The method of claim 1, wherein the RADIUS request message is an Accounting-Start message and the Diameter request message is Credit-Control-Request (CCR) message.

9. A system comprising: a Diameter signaling router (DSR) including at least one message processor;a remote authentication dial in user service (RADIUS) connection layer, implemented using the DSR, for detecting a remote authentication dial in user service (RADIUS) access session for a user device, including identifying a policy node from a plurality of policy nodes and binding the RADIUS access session to the policy node and routing RADIUS messages for the RADIUS access session from the DSR to the policy node, wherein detecting the RADIUS access session comprises receiving a request message from an access gateway, routing the request message to a policy and charging rules function (PCRF) configured to receive and process both RADIUS and Diameter messages and to provide one or more policy services for both RADIUS and Diameter access sessions, and routing a response message from the PCRF to the access gateway to establish a fixed network connection for the user device;a policy charging application, implemented using the DSR, for correlating the RADIUS access session with the Diameter session, including binding the Diameter session to the policy node in response to determining that the Diameter session corresponds to the RADIUS access session and routing Diameter messages for the Diameter session from the DSR to the policy node;wherein the policy charging application is configured for, after correlating the RADIUS access session with the Diameter session, routing both the RADIUS messages for the RADIUS access session for the user device to the policy node and the Diameter messages for the RADIUS access session for the same user device to the policy node.

10. The system of claim 9, wherein the DSR is configured to detect the Diameter session by receiving a request message from an application function (AF) or a traffic detection function (TDF) or the access gateway and routing the request message to the PCRF and routing a response message from the PCRF to the AF or TDF or access gateway.

11. The system of claim 9, wherein detecting the RADIUS access session comprises storing RADIUS session information for the RADIUS access session in a stateful session database.

12. The system of claim 11, wherein correlating the RADIUS access session with the Diameter session comprises comparing Diameter session information for the Diameter session with the RADIUS session information.

13. The system of claim 11, wherein storing RADIUS session information comprises storing an Acct-Session-ID value and an Internet protocol (IP) address or subscriber identifier from a RADIUS Accounting-Request message.

14. The system of claim 9, wherein detecting the RADIUS access session comprises maintaining a session timer for the RADIUS access session, updating the session timer each time a message is processed for the RADIUS access session, and, in response to detecting a session timeout using the session timer, deleting the RADIUS access session and any bindings for the RADIUS access session.

15. The system of claim 9, comprising receiving a Change-of-Authorization (CoA) command from the policy node and routing the CoA command for policy installation and/or removal for the RADIUS access session.

16. The system of claim 9, wherein the RADIUS request message is an Accounting-Start message and the Diameter request message is Credit-Control-Request (CCR) message.

17. A non-transitory computer readable medium having stored thereon executable instructions that when executed by a processor on a computer control the computer to perform steps comprising: detecting a remote authentication dial in user service (RADIUS) access session for a user device, including identifying a policy node from a plurality of policy nodes and binding the RADIUS access session to the policy node and routing RADIUS messages for the RADIUS access session from the DSR to the policy node, wherein detecting the RADIUS access session comprises receiving a request message from an access gateway, routing the request message to a policy and charging rules function (PCRF) configured to receive and process both RADIUS and Diameter messages and to provide one or more policy services for both RADIUS and Diameter access sessions, and routing a response message from the PCRF to the access gateway to establish a fixed network connection for the user device;detecting a Diameter session for the user device;correlating the RADIUS access session with the Diameter session, including binding the Diameter session to the policy node in response to determining that the Diameter session corresponds to the RADIUS access session and routing Diameter messages for the Diameter session from the DSR to the policy node; andafter correlating the RADIUS access session with the Diameter session, routing both the RADIUS messages for the RADIUS access session for the user device to the policy node and the Diameter messages for the RADIUS access session for the user device to the policy node.