Policy node identifier for application services in a packet core network

Node identifiers can be assigned to packet core policy nodes and directly routed to a diameter routing agent (DRA) and application functions (AFs) within a call processing message that is employed to establish an application service. Such a policy node identity will be received by Application Functions, UEs and/or intermediate message routers during the initial establishment of a packet data session so that they can refer to the policy node entity directly in the sub-sequent call processing flows related the established session, instead of querying a relational database which can be complex to maintain with multi-million correlation records. As an example, the policy node identifiers can be configurable and can comprise a hostname of the policy nodes, address data associated with the policy nodes, or a defined numerical value that maps to the hostname of the policy nodes.

TECHNICAL FIELD

The subject disclosure relates to wireless communications, e.g., policy node identifier utilized for application services in a packet core network.

BACKGROUND

Long Term Evolution (LTE) networks support a large number of application services (e.g. voice over LTE (VoLTE), video streaming and/or download services, content delivery services, etc.) and will continue to add new revenue-generating services (e.g. dynamic traffic management). With mobile data and voice traffic growing exponentially, service reliability has become a crucial factor for the LTE network. Moreover, it is important that services are delivered seamlessly, and service disruptions are avoided.

In conventional systems, when a user equipment (UE) attaches to an LTE network and initiates application service, several packet core nodes are employed in the call flow for service delivery, such as, a mobility management entity (MME), a serving and packet gateway (S/PGW), a diameter routing agent (DRA), a policy and charging rules function (PCRF) and an application function (AF). During a UE attach procedure, the MME sends a Create Session Request to the S/PGW, which then sends a Credit Control Request (CCR-I) to the PCRF via the DRA. The PCRF responds to S/PGW with a Credit Control Answer (CCA-I) and the S/PGW then sends Create Session Response to the MME. Traditionally, the DRA stores the PCRF routing information per Internet protocol-connectivity access network (IP-CAN) session in a binding database. This routing information is critical for delivering application services. For application services to be established, an Rx message comprising an identifier of the UE is sent from the AF to the DRA. The DRA can then determine the PCRF hosting the IP-CAN session by querying the binding database.

Typically, the binding database comprises millions of records. Management and maintenance of such a large number of records can be complex. Further, unavailability of this binding database can directly impact application services and result in substantial revenue loss.

DETAILED DESCRIPTION

One or more embodiments are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. It may be evident, however, that the various embodiments can be practiced without these specific details, e.g., without applying to any particular networked environment or standard. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the embodiments in additional detail.

As used in this application, the terms “component,” “module,” “system,” “interface,” “node,” “platform,” “server,” “controller,” “entity,” “element,” “function,” “gateway,” “agent,” or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution or an entity related to an operational machine with one or more specific functionalities. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, computer-executable instruction(s), a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. As another example, an interface can comprise input/output (I/O) components as well as associated processor, application, and/or API components.

Moreover, terms like “user equipment,” “mobile station,” and similar terminology, refer to a wired or wireless communication-capable device utilized by a subscriber or user of a wired or wireless communication service to receive or convey data, control, voice, video, sound, gaming, or substantially any data-stream or signaling-stream. The foregoing terms are utilized interchangeably in the subject specification and related drawings. Data and signaling streams can be packetized or frame-based flows. Further, the terms “user,” “subscriber,” “consumer,” and the like are employed interchangeably throughout the subject specification, unless context warrants particular distinction(s) among the terms. It should be noted that such terms can refer to human entities or automated components supported through artificial intelligence (e.g., a capacity to make inference based on complex mathematical formalisms), which can provide simulated vision, sound recognition and so forth.

It should be noted that although various aspects and embodiments have been described herein in the context of 5G and/or long term evolution (LTE), or other next generation networks, the disclosed aspects are not limited to 5G, a UMTS implementation, and/or an LTE implementation as the techniques can also be applied in 3G or other network systems. For example, aspects or features of the disclosed embodiments can be exploited in substantially any wireless communication technology. Such wireless communication technologies can include universal mobile telecommunications system (UMTS), code division multiple access (CDMA), Wi-Fi, worldwide interoperability for microwave access (WiMAX), general packet radio service (GPRS), enhanced GPRS, third generation partnership project (3GPP), LTE, third generation partnership project 2 (3GPP2) ultra mobile broadband (UMB), high speed packet access (HSPA), evolved high speed packet access (HSPA+), high-speed downlink packet access (HSDPA), high-speed uplink packet access (HSUPA), Zigbee, or another IEEE 802.XX technology. Additionally, substantially all aspects disclosed herein can be exploited in legacy telecommunication technologies.

As used herein, “5G” can also be referred to as New Radio (NR) access. Accordingly, systems, methods, and/or machine-readable storage media for facilitating improved communication coverage for 5G systems are desired. As used herein, one or more aspects of a 5G network can comprise, but is not limited to, data rates of several tens of megabits per second (Mbps) supported for tens of thousands of users; at least one gigabit per second (Gbps) to be offered simultaneously to tens of users (e.g., tens of workers on the same office floor); several hundreds of thousands of simultaneous connections supported for massive sensor deployments; spectral efficiency significantly enhanced compared to 4G; improvement in coverage relative to 4G; signaling efficiency enhanced compared to 4G; and/or latency significantly reduced compared to LTE.

Conventional evolved pack core (EPC) networks rely on a binding database coupled to a diameter routing agent (DRA) to forward an application request to the correct Policy and Charging Rules Function (PCRF) that hosts a session related to the application request. In particular, the DRA binding database comprises records for PCRF routing information per IP connectivity access network (IP-CAN) session. Thus, each user equipment (UE) coupled to the packet core network can have multiple records stored in the binding database (e.g., a first record for international mobile subscriber identity (IMSI)+access point name (APN), a second record for mobile station international subscriber directory number (MSISDN)+APN, a third record for Internet Protocol version 6 (IPv6)). Accordingly, the binding database for a large communication network can comprise millions of records. Unavailability of this binding database can cause application service outage, resulting in a significant revenue loss. Moreover, without the binding database, there is no way for the DRA to process incoming application service requests and route the requests to appropriate host PCRFs. For example, when a binding database is not available, and a UE initiates a voice over LTE (VoLTE) call, the VoLTE call will fail until the binding database is restored. The same is true for other application services as well. To overcome these challenges, the systems and methods disclosed herein relate to processing application service requests without implementing and/or employing a DRA binding database. In contrast with conventional systems, the systems and methods disclosed herein utilize node identifiers assigned to packet core nodes and route the node identifiers to the DRA within a call flow message that is employable to establish an application service.

Referring initially toFIG. 1, there illustrated is an example system100that facilitates an establishment of application services based on routing of node identifier data, according to one or more aspects of the disclosed subject matter. In one aspect, system100enables a DRA102to accurately determine a policy node, for example, a host PCRF104, for establishing a dedicated bearer for an application service requested by a UE106. As an example, the UE106can comprise, but is not limited to, most any industrial automation device and/or consumer electronic device, for example, a tablet computer, a digital media player, a wearable device, a digital camera, a media player, a cellular phone, a personal computer, a personal digital assistant (PDA), a smart phone, a laptop, a gaming system, set top boxes, home security systems, an Internet of things (IoT) device, a connected vehicle, at least partially automated vehicle (e.g., drones), etc. System100can be part of most any communication network, such as, but not limited to an LTE network, a 5G network and/or other next-generation networks.

The DRA102is employed to provide real-time routing functions that allow messages to be routed to the correct network devices. In one aspect, the DRA102can facilitate session binding (e.g., in IP-CAN sessions) towards the PCRF104. Moreover, the session binding is utilized to handle multiple Diameter sessions in application services. For example, in VoLTE services, the LTE parts of a VoLTE call, together with the IP Multimedia Subsystem (IMS) parts of the call, are controlled by the same PCRF (e.g., PCRF104). Additionally, consistent policy rules need to be applied to the session that are related to the same VoLTE call. The PCRF104can be utilized to implement policy control decision and flow-based charging control functionalities. The PCRF104can provide network control regarding the service data flow detection, gating, quality of service (QoS) and flow-based charging towards a policy and charging enforcement function (PCEF) (not shown). An application function (AF)114, can provide session and media related information to the PCRF104, which in turn can notify the AF114of traffic plane events. In case of VoLTE, the PCRF104can communicate with devices of the IMS network for establishing the VoLTE calls and allocating the requested bandwidth to the call bearer, for example, with configured attributes.

When UE106initially registers with the network, for example via an access network108, a default bearer is established for communicating with the network or applications. As part of UE attach procedure, the serving MME (e.g., MME110) sends a request (e.g., create session request (CSR)) to the serving and packet data network gateway (PGW) (e.g., S/PGW112), which then sends a request (e.g., a Gx credit control request (CCR-I)) to a host PCRF104via the DRA102. The host PCRF104can respond to the request (e.g., by transmitting a Gx credit control answer (CCA-I)) and initiate establishment of the default bearer. When the UE106initiates an application service (e.g., makes a VoLTE call) via application function (AF)114(e.g., proxy-call session control function (P-CSCF) in case of VoLTE service), the same PCRF that was employed to establish the default bearer (e.g., PCRF104) is to be utilized to establish a dedicated bearer for the application service.

According to an aspect, to ensure that the host PCRF104is accurately determined during application service establishment, system100facilitates routing of identifier information associated with the packet core nodes (e.g., PCRF104, S/PGW112, etc.). For example, the node identifiers for PCRF104and S/PGW112can be introduced into the end-to-end application call flow. In an aspect, the node identifiers are configurable and can be assigned as the hostname of the node or most any defined identifier (e.g., 16-bit identifier). In one aspect, during establishment of the default bearer, the PCRF104can transmit its identifier to the S/PGW112via the DRA102. For example, the identifier can be included within and/or appended to a Gx CCA-I message. In another example, the identifier can be transmitted within a new message. In one embodiment, the node identifiers can be deployed in the core network, such that on default bearer establishment, the S/PGW112can notify the AF114with node identifier for the PCRF104as well as the S/PGWs112's identifier. In this example scenario, the AF114can store the identifiers and provide them to the DRA102on receiving an application service request from the UE106. The DRA102can utilize the identifiers to direct the request to the appropriate host PCRF104to facilitate establishment of the dedicated bearer for the application service.

In another embodiment, the node identifiers can be extended to the UE106, such that on default bearer establishment, the S/PGW112can relay the node identifiers to the UE106. In this example embodiment, the identifiers can be stored within the UE106and can be transmitted to the AF114within (and/or along with) an application service request. The AF114can then forward the identifiers to the DRA102, which can utilize the identifiers to direct the request to the appropriate host PCRF104to facilitate establishment of the dedicated bearer for the application service. These embodiments enable the DRA102to efficiently determine host PCRFs independent of using and/or maintaining a large binding database.

It is noted that the network functions shown in the figures are for illustration purposes and that the subject embodiment architecture can be extended to other network implementations. For example, theFIG. 1shows the combined Serving GW and Packet GW (e.g., S/PGW112). However, the implementation can also combine the MME110with the SGW and PGW (e.g., S/PGW112) is an independent network function. This principle applies to any wireless network implementation variations.

Referring now toFIGS. 2A-D, there illustrated is an example end-to-end application call flow (200,225,250,275) that deploys a policy node identifier in packet core network devices, in accordance with an aspect of the subject disclosure. It is noted that the DRA102, PCRF04, UE106, S/PGW112, and AF114can comprise functionality as more fully described herein, for example, as described above with regard to system100. Although the call flow (200,225,250,275) has been described with respect to an LTE network, it is noted that the subject disclosure is not limited to LTE networks and can be utilized in most any communication network.

FIGS. 2A-Dprovide an easy-to-deploy solution that provides an efficient way to find the correct PCRF (e.g., host PCRF for a session) while minimizing service impact to end-user or application. According to an aspect, the core network policy nodes, for example, PCRF104and S/PGW112, can be assigned respective identifiers within the network. In an example, the identifiers can comprise 16 bits. In another example, the identifier can comprise, but is not limited to, a hostname of the node, a numeric number, IP address, or a L2 link address. According to an aspect, end-to-end application call flows can be modified to transfer the identifier data during the call flow to facilitate PCRF determination. In an aspect, a SGi interface between S/PGW and P-CSCF can be utilized to convey and/or update the identifier data.

Referring toFIG. 2A, when UE106attaches to the network (e.g., during power up, entry within a coverage area of the network, etc.), a request (e.g., CSR) is sent from the MME (shown inFIG. 1) to the S/PGW112. As depicted at (1), the S/PGW112sends a request (e.g., Gx CCR-I) to establish a default bearer, to the DRA102, which can then determine a PCRF, for example, PCRF104to service the request. At (2), the DRA relays the request (e.g., Gx CCR-I) to the PCRF104. At (3), the PCRF104transmits a response (e.g., Gx CCA-I (with PCRF ID)) to the DRA102. In one aspect, PCRF104's identifier is included within and/or appended to the response. At (4), the DRA102can relay the response (and PCRF ID) to the S/PGW112, which can then send a create session response to MME to facilitate establishment of a default bearer for the UE106.

Referring toFIG. 2B, when the response (e.g., Gx CCA-I (with PCRF ID)) is received from the PCRF104and the default bearer is successfully established, at (5) the S/PGW112can send a notify message (e.g., in-band and/or out-of-band) to AF114. As an example, the notify message can comprise information, such as, but not limited to, bearer information, the PCRF ID, and the S/PGW112's identifier (e.g., PGW ID). Alternatively, the identifiers (e.g., PCRF ID and PGW ID) can be transmitted within (and/or appended to) a session initiation protocol (SIP) Register message. In one aspect, an existing link between the S/PGW112and the AF114can be leveraged to transfer the identifiers. The AF114can store the transferred information within its data store and at (6) can transmit an acknowledge message back to the S/PGW112.

Referring now toFIG. 2C, when an application service is to be initiated, (e.g., at (7) UE106can send a SIP INVITE message to AF114), the AF114can determine the stored PCRF and PGW identifiers and generate a Rx AA-Request (AAR) that comprises the PCRF and PGW identifiers. In case the notify message is not received at the time of the SIP INVITE message arrival, at (7a) the AF114can pull the node identifiers from the S/PGW112to avoid any race conditions. At (8), the AF114can transfer the Rx AAR and the PCRF and PGW identifiers to the DRA102. The DRA102can identify the PCRF hostname from the received PCRF identifier and at (9) route the message to the correct PCRF. Since the destination node information is provided in the Rx AAR, the implementation and/or maintenance of a complex binding database can be avoided. At (10) and (11), an Rx AA Answer (AAA) message can be transferred from the PCRF104to the AF114via the DRA102.

FIG. 2Dillustrates establishment of a dedicated bearer. The PCRF104can determine a Gx session to which the incoming Rx AAR should be bound. Further, the PCRF104can create charging rules and at (12) and (13) send a message (e.g., Gx RAR) to S/PGW112via the DRA102. At (14) and (15), the S/PGW112can respond (e.g., Gx RAA) to the PCRF104via the DRA102. Further, the S/PGW112can then establish a dedicated bearer for the application service associated with (e.g., initiated by) UE106.

Referring now toFIGS. 3A-B, there illustrated an example end-to-end application call flow (300,350) that deploys policy node identifier in UEs, in accordance with an aspect of the subject disclosure.FIGS. 3A-Bprovide a long-term solution that delivers an efficient way for a DRA102to find the correct PCRF while eliminating a dependency on centralized binding database comprising millions of records. It is noted that the DRA102, PCRF04, UE106, S/PGW112, and AF114can comprise functionality as more fully described herein, for example, as described above with regard to system100. Although the call flow (300,350) has been described with respect to an LTE network, it is noted that the subject disclosure is not limited to LTE networks and can be utilized in most any communication network that employs a policy driven service architecture.

Similar to flow200, when UE106attaches to the network (e.g., during power up, entry within a coverage area of the network, etc.), a request (e.g., create session request) is sent from the MME110to the S/PGW112. The S/PGW112can send a request to establish a default bearer (e.g., Gx CCR-I) to the DRA102, which can then determine a destination PCRF, for example, PCRF104to service the request. The DRA can then relay the request (e.g., Gx CCR-I) to the PCRF104. At (1), the PCRF104can transmit a response (e.g., Gx CCA-I (with PCRF ID)) to the DRA102. In one aspect, PCRF104's identifier can be included within and/or appended to the response. At (2), the DRA102can relay the response (and PCRF ID) to the S/PGW112. In this embodiment, at (3), the S/PGW112can transmit the response to the MME110along with the PCRF ID and the S/PGW112's identifier (PGW ID). For example, the PCRF and PGW IDs can be included as an information element (IE) in a GPRS tunneling protocol (GTP) create session response to MME110. The MME110can facilitate establishment of a default bearer for the UE106. At (4), the MME110can send the PCRF and PGW IDs to the UE106, for example, in a non-access stratum (NAS) message (e.g., ESM Message Container IE). The identifiers can be stored and maintained in a data store of the UE106.

Referring toFIG. 3B, subsequent to the establishment of the default bearer, service requests (e.g., VoLTE SIP call) initiated by the UE106can comprise the PCRF and PGW IDs (at (5)). At (6), the MME110can relay the request and IDs to the S/PGW112, which can provide the request data (comprising the IDs) to the AF114(at (7)). The AF114can include/insert/append the PCRF ID attribute value pair (AVP) in a diameter request message that is transmitted to the DRA102(at (8)). On receipt of the request, the DRA102can query a global node identifier to hostname mapping table to identify the destination PCRF and at (9) route the message to the identified PCRF104. It is noted that the mapping table utilized by the DRA102is much smaller than a conventional binding database. Moreover, the mapping table simply comprises one entry per PCRF coupled to the DRA, resulting in a table with much smaller entry sizes (<<1000 entries) depending on the carrier network size. In contrast, the conventional binding database comprises millions of records based on number of application sessions. Accordingly, since the mapping table is significantly smaller, the work performed by DRA102for determining a destination PCRF is substantially reduced. In one example, the DRA102can dynamically maintain and/or update the mapping table by receiving information (e.g., periodically) from the PCRFs and/or other DRAs. At (10) and (11), an Rx AAA message can be transferred from the PCRF104to the AF114via the DRA102. A dedicated bearer can then be established (e.g., as shown in call flow275).

It is noted that the call flow (200-275) depicted inFIGS. 2A-2Dis easier to deploy as compared to the call flow (330-35) depicted inFIGS. 3A-3Bsince only the packet core nodes and their call flows are modified in200-275, whereas300-350extends the node identifier deployment to the MME and UE (e.g., which can typically take longer to implement).

Referring now toFIG. 4, there illustrated is an example system400that routes node identifiers to a DRA to facilitate PCRF selection, according to an aspect of the subject disclosure. It is noted that the DRA102and AF114can comprise functionality as more fully described herein, for example, as described above with regard to systems100-300. According to an aspect, policy network nodes (e.g., PCRF, PGW) can be assigned an identifier in the network. As an example, the identifier can comprise a hostname, a numeric number, IP address, L2 link address, etc. In another example, the identifier can comprise a 16-bit identifier that applies to a pool of nodes that share a common session database, wherein the higher 8-bit can be reserved for a first node, for example, a PGW and the lower 8-bit can be reserved for a second node, for example, a PCRF. The identifier can be configured and/or updated at most any time.

In a first embodiment, wherein changes are made only within the core network (e.g., depicted in detail with respect to call flows200-275), the identifier can comprise a hostname of the node. In this example embodiment, PGW and PCRF identifiers can be introduced into the default bearer establishment for a served UE, such that the PCRF can utilize an interface between the PCRF and the PGW (e.g., Sgi interface) to convey and/or update the identifiers. According to an aspect, an ID determination component402can receive identifier data (e.g., PCRF ID and PGW ID) from the PGW serving the UE. As an example, the identifier data can be received in a push or pull configuration. In one aspect, the identifier data can be received via in-band and/or out-of band communication. In yet another aspect, the identifier data can be received via a SIP register message. The ID determination component402can store the identifier data (e.g., linked to the UE/session/bearer information), within a data store404. When determined that an application service is initiated by the UE (e.g., a SIP INVITE message is received from the UE), an ID transmission component406can be utilized to transfer the identifier data (e.g., PCRF ID and PGW ID) associated with the UE to the DRA102. As an example, the ID transmission component406can insert/append the identifier data within/to an Rx AAR message. Alternatively, the ID transmission component406can transfer the identifier data via a new message. In an aspect, an ID extraction component408can extract the identifier data from the received message, a PCRF selection component410can determine (e.g., based on the PCRF hostname determined from the PCRF identifier) a destination PCRF to which the message (e.g., Rx AAR message) is to be relayed, and the DRA102can transmit the message to the determined PCRF to facilitate establishment of a dedicated bearer. Accordingly, the DRA102can efficiently determine a destination PCRF without searching through millions of records of a binding database.

In a second embodiment, wherein changes are extended to the MME and UE (e.g., depicted in detail with respect to call flows300-350), the identifier can comprise a 16-bit identifier that can map to a PGW hostname and a PCRF hostname. In this example embodiment, PGW and PCRF identifiers can be introduced into the default bearer establishment for a served UE, such that the PCRF can utilize an interface between the PCRF and the PGW (e.g., Sgi interface) to convey and/or update the 16-bit identifier and further, the PGW/serving gateway (SGW) can include the identifier as an IE in a GTPv2-C Create Session Response to a MME, which in turn can send the identifier to the UE in a NAS Message (e.g., ESM Message Container IE). The identifier can be stored and maintained in the UE. Moreover, the UE can transmit the identifier in (and/or along with) subsequent service related messages (e.g. VoLTE SIP call) to the AF114. On receiving the service related message, the ID determination component402can extract the identifier and the ID transmission component406can add the identifier, for example, as a node identifier AVP, in the diameter message and transmit the diameter message to the DRA102. The ID extraction component408can receive the diameter message and determine the node identifier AVP. Further, the PCRF selection component410can utilize the AVP to query a mapping table412to determine the PCRF host name. In one example, the mapping table412can store a mapping of node identifiers with hostnames of destination nodes. Based on the PCRF host name, the DRA102can forward the diameter message to the appropriate PCRF. This approach is very efficient in finding the right PCRF or policy node and eliminates the dependency on centralized binding database which contains millions of records.

Referring now toFIG. 5, there illustrated is an example system500that facilitates configuration of policy node identifiers in accordance with the subject embodiments. It is noted that the DRA102, PCRF104, and S/PGW112can comprise functionality as more fully described herein, for example, as described above with regard to systems100-400. According to an aspect, when node identifiers are extended to the MME and UE (e.g., depicted in detail with respect to call flows300-350), network nodes, such as PCRF104and S/PGW112, can be configured with a common identifier to facilitate detection during dedicated bear establishment. As an example, the identifier can comprise a 16-bit identifier (e.g., Hex) that can represent both the host S/PGW112and the host PCRF104(e.g., eight bits reserved for each node). The identifier can be maintained by node (e.g., PCRF104and/or S/PGW112) and shared with the ID configuration component502, at most any time, such as, but not limited to, during a node power-up, periodically, in response to an event, on-demand, etc. The ID configuration component502can store the identifier with corresponding node hostnames in the mapping table412as shown below:

As described in detail with regards to call flow300-350, the identifier is transferred to the UE during default bearer establishment and then transmitted by the UE to the AF during service initiation. The AF provides the identifier to the DRA102as part of (and/or along with) a diameter request. Moreover, the DRA102can utilize the mapping table412to determine hostnames for the nodes and select appropriate nodes, to which the diameter request is to be relayed (e.g., to facilitate dedicated bearer establishment).

FIG. 6illustrates an example system600that facilitates a generation of a global mapping table in accordance with the subject embodiments. It is noted that the DRAs6021-602N(wherein N is most any integer greater than 1) are substantially similar to DRA102and can comprise functionality as more fully described herein, for example, as described above with regard to DRA102. Further, PCRF/PGW6041-604M(wherein M is most any integer greater than 1) are substantially similar to PCRF104and/or S/PGW112and can comprise functionality as more fully described herein, for example, as described above with regard to PCRF104and/or S/PGW112. According to an embodiment, DRAs6021-602Ncan auto-learn (e.g., via a push or pull configuration) node identifier data associated with connected nodes (e.g., PCRF/PGW6041-604M) and add it to a global mapping table comprising a node identifier to hostname mapping (e.g., mapping table412within one or more of DRAs6021-602Nand/or a network data store coupled to network606).

Referring now toFIG. 7there illustrated is an example method700that efficiently determines a host policy node during establishment of a dedicated bearer, according to an aspect of the subject disclosure. In an aspect, method700can be implemented by one or more network devices (e.g., core network devices) of a communication network (e.g., cellular network). At702, network identifiers can be assigned to core network policy nodes (e.g., PCRF and/or PGW). As an example, the network identifiers can comprise a hostname, a numeric value, an IP address, a L2 link address, etc. At704, during default bearer establishment associated with a UE (e.g., when a UE powers on, enters the network coverage area, etc.), a policy node identifier, for example, a host PCRF ID, can be conveyed to a gateway node, for example, a S/PGW. As an example, the PCRF ID can be transmitted within and/or appended to a Gx CCA-I message. When the default bearer is successfully established, at706, the host PCRF ID and a PGW ID can be transferred to an AF (e.g., a P-CSCF), for example, via in-band signaling, via out-of band signaling, via a SIP register message, etc.

Further, at708in response to determining that an application service has been initiated by the UE (e.g., based on receiving a SIP INVITE message from the UE), the host PCRF ID and PGW ID can be transferred to a DRA via a diameter request (e.g., Rx AAR message). At710, based on the received host PCRF ID, the diameter request can be relayed to an appropriate PCRF to facilitate an establishment of a dedicated bearer associated with the application service.

FIG. 8illustrates an example method800that facilitates a detection of a host policy node based on a transfer of identifier data to a UE, according to an aspect of the subject disclosure. As an example, method800can be implemented by one or more network devices of a communication network (e.g., cellular network). At802, network identifiers can be assigned to core network policy nodes (e.g., PCRF and/or PGW). As an example, the network identifiers can comprise a 16-bit identifier that maps to hostnames of the PCRF and/or PGW. At804, during default bearer establishment associated with a UE (e.g., when a UE powers on, enters the network coverage area, etc.), identifier data associated with the policy nodes, for example, PCRF and PGW, can be conveyed to the UE via a MME. For example, the PGW can include the identifier data as an IE in a GTPv2-C Create Session Response to the MME, which in turn can send the identifier data to the UE in a NAS Message (e.g., ESM Message Container IE). The identifier data can then be stored and maintained in the UE.

At806, the identifier data can be received with (e.g., inserted within and/or appended to) an application service request sent from the UE to initiate an application service. For example, the UE can transmit a SIP INVITE message, that comprises the identifier data, to P-CSCF to initiate a VoLTE call. In response to receiving the application service request, at808, the identifier data can be transferred to a DRA via a diameter request (e.g., Rx AAR message). Further, at810, based on the identifier data, a PCRF hostname can be retrieved from a mapping table and the diameter request can be relayed to the appropriate PCRF to facilitate an establishment of a dedicated bearer associated with the application service.

In one aspect, the systems100-600and methods700-800disclosed herein provide various non-limiting advantages, for example, (i) eliminating dependence on a binding database to find the correct PCRF for AF; (ii) improving PCRF detection efficiency; (iii) minimizing service impact to end-user and/or application; (iv) addressing VoLTE and/or other application service resiliency issues without utilizing a DRA binding database; (v) reducing cost and maintenance of DRA upgrade (e.g., since a binding database is not required); (vi) enabling development of new application services; etc.

Referring now toFIG. 9, there is illustrated a block diagram of a computer902operable to execute the disclosed communication architecture. In order to provide additional context for various aspects of the disclosed subject matter,FIG. 9and the following discussion are intended to provide a brief, general description of a suitable computing environment900in which the various aspects of the specification can be implemented. While the specification has been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the specification also can be implemented in combination with other program modules and/or as a combination of hardware and software.

The illustrated aspects of the specification can also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

A computing device can typically include a variety of machine-readable media. Machine-readable media can be any available media that can be accessed by the computer and includes both volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, computer-readable media can comprise computer storage media and communication media. Computer storage media can include volatile and/or non-volatile media, removable and/or non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media can include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, solid state drive (SSD) or other solid-state storage technology, Compact Disk Read Only Memory (CD ROM), digital video disk (DVD), Blu-ray disk, or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer. In this regard, the terms “tangible” or “non-transitory” herein as applied to storage, memory or computer-readable media, are to be understood to exclude only propagating transitory signals per se as modifiers and do not relinquish rights to all standard storage, memory or computer-readable media that are not only propagating transitory signals per se.

With reference again toFIG. 9, the example environment900for implementing various aspects of the specification comprises a computer902, the computer902comprising a processing unit904, a system memory906and a system bus908. As an example, the component(s), application(s) server(s), equipment, system(s), interface(s), gateway(s), controller(s), node(s), entity(ies), function(s), cloud(s), agent(s), entity(ies), and/or device(s) (e.g., DRA102, PCRF104, UE106, devices of network108, MME110, S/PGW112, AF114, ID determination component402, ID transmission component406, ID extraction component408, PCRF selection component410, ID configuration component502, DRAs6021-602N, PCRF/PGW6041-604M, devices of network606, etc.) disclosed herein with respect to systems100-500can each comprise at least a portion of the computer902. The system bus908couples system components comprising, but not limited to, the system memory906to the processing unit904. The processing unit904can be any of various commercially available processors. Dual microprocessors and other multi-processor architectures can also be employed as the processing unit904.

The system bus908can be any of several types of bus structure that can further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory906comprises read-only memory (ROM)910and random access memory (RAM)912. A basic input/output system (BIOS) is stored in a non-volatile memory910such as ROM, EPROM, EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer902, such as during startup. The RAM912can also comprise a high-speed RAM such as static RAM for caching data.

The computer902further comprises an internal hard disk drive (HDD)914, which internal hard disk drive914can also be configured for external use in a suitable chassis (not shown), a magnetic floppy disk drive (FDD)916, (e.g., to read from or write to a removable diskette918) and an optical disk drive920, (e.g., reading a CD-ROM disk922or, to read from or write to other high capacity optical media such as the DVD). The hard disk drive914, magnetic disk drive916and optical disk drive920can be connected to the system bus908by a hard disk drive interface924, a magnetic disk drive interface926and an optical drive interface928, respectively. The interface924for external drive implementations comprises at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. Other external drive connection technologies are within contemplation of the subject disclosure.

A number of program modules can be stored in the drives and RAM912, comprising an operating system930, one or more application programs932, other program modules934and program data936. All or portions of the operating system, applications, modules, and/or data can also be cached in the RAM912. It is noted that the specification can be implemented with various commercially available operating systems or combinations of operating systems.

A user can enter commands and information into the computer902through one or more wired/wireless input devices, e.g., a keyboard938and/or a pointing device, such as a mouse940or a touchscreen or touchpad (not illustrated). These and other input devices are often connected to the processing unit904through an input device interface942that is coupled to the system bus908, but can be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc. A monitor944or other type of display device is also connected to the system bus908via an interface, such as a video adapter946.

The computer902can operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s)948. The remote computer(s)948can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically comprises many or all of the elements described relative to the computer902, although, for purposes of brevity, only a memory/storage device950is illustrated. The logical connections depicted comprise wired/wireless connectivity to a local area network (LAN)952and/or larger networks, e.g., a wide area network (WAN)954. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, e.g., the Internet.

When used in a LAN networking environment, the computer902is connected to the local network952through a wired and/or wireless communication network interface or adapter956. The adapter956can facilitate wired or wireless communication to the LAN952, which can also comprise a wireless access point disposed thereon for communicating with the wireless adapter956.

When used in a WAN networking environment, the computer902can comprise a modem958, or is connected to a communications server on the WAN954or has other means for establishing communications over the WAN954, such as by way of the Internet. The modem958, which can be internal or external and a wired or wireless device, is connected to the system bus908via the serial port interface942. In a networked environment, program modules depicted relative to the computer902, or portions thereof, can be stored in the remote memory/storage device950. It will be noted that the network connections shown are example and other means of establishing a communications link between the computers can be used.

The computer902is operable to communicate with any wireless devices or entities operatively disposed in wireless communication, e.g., desktop and/or portable computer, server, communications satellite, etc. This comprises at least Wi-Fi and Bluetooth™ wireless technologies or other communication technologies. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices.

Wi-Fi, or Wireless Fidelity networks use radio technologies called IEEE 802.11 (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3 or Ethernet). Wi-Fi networks operate in the unlicensed 2.4 and 5 GHz radio bands, at an 11 Mbps (802.11a) or 54 Mbps (802.11b) data rate, for example, or with products that contain both bands (dual band), so the networks can provide real-world performance similar to the basic 10BaseT wired Ethernet networks used in many offices.

Referring now toFIG. 10, there is illustrated a schematic block diagram of a computing environment1000in accordance with the subject specification. The system1000comprises one or more client(s)1002. The client(s)1002can be hardware and/or software (e.g., threads, processes, computing devices).

The system1000also comprises one or more server(s)1004. The server(s)1004can also be hardware and/or software (e.g., threads, processes, computing devices). The servers1004can house threads to perform transformations by employing the specification, for example. One possible communication between a client1002and a server1004can be in the form of a data packet adapted to be transmitted between two or more computer processes. The data packet may comprise a cookie and/or associated contextual information, for example. The system1000comprises a communication framework1006(e.g., a global communication network such as the Internet, cellular network, etc.) that can be employed to facilitate communications between the client(s)1002and the server(s)1004.

Communications can be facilitated via a wired (comprising optical fiber) and/or wireless technology. The client(s)1002are operatively connected to one or more client data store(s)1008that can be employed to store information local to the client(s)1002(e.g., cookie(s) and/or associated contextual information). Similarly, the server(s)1004are operatively connected to one or more server data store(s)1010that can be employed to store information local to the servers1004.