Patent Description:
A <NUM> Core (5GC) network includes various functions relating to tracking usage of the 5GC by various devices connected to the 5GC. In particular, the 5GC includes a Charging Function (CHF) configured to provide charging services to the 5GC. In addition, the CHF is configured to communicate with external billing systems. <CIT> discloses a SMF including a buffer. When the SMF is unable to access a CHF during an outage, the SMF can buffer charging events in the buffer and allow service to users based on configuration (fail-open mode). <CIT> discloses a network platform that may determine that a subscriber data storage is non-responsive and it may execute a fail-open function in response to determining that the subscriber data storage is non-responsive.

There is provided a method and a fail open function as defined in the claims.

The systems, devices, and techniques described herein relate to techniques for providing CHF fallback in a 5GC. In various implementations, the CHF can be integral to charging services within the 5GC. The CHF includes a database that stores subscriber information. This information indicates the type of data services used by a subscriber, a type of plan the subscriber has with the 5GC, and so on. The CHF may provide feedback to other elements of the 5GC if the subscriber's plan limits a session associated with the subscriber (e.g., limits the amount of data that can be transmitted in the session) and/or indicates a priority of the session within the 5GC. According to some implementations, the CHF may track usage of 5GC resources by the subscriber. In particular examples, the CHF interacts with a session management function (SMF) and/or a policy control function (PCF) within the 5GC as the session is being established and/or as the session continues.

The CHF is a critical function in the 5GC. Accordingly, if the CHF is at least partially offline or otherwise unreachable by other functions within the 5GC, charging services may be significantly interrupted. In some cases, when the CHF is offline or otherwise unreachable, the 5GC may be unable to apply predetermined policies to sessions associated with individual subscribers and/or may be unable to track usage of the 5GC by the subscribers.

According to various cases described herein, a Fail-Open Function (FOF) is introduced to the 5GC. The FOF is configured to store a copy of subscriber information that is stored in the CHF. In some cases, the FOF may be implemented by one or more first hardware devices (e.g., servers), the CHF may be implemented by one or more second hardware devices (e.g., servers), wherein the first hardware device(s) are different than the second hardware device(s). Furthermore, the FOF may be reachable via a first communications interface, the CHF may be reachable via a second communications interface, wherein the first communications interface(s) are different than the second communications interface(s). Thus, the FOF may remain online and/or reachable even if the CHF is not.

When the CHF is at least partially offline or otherwise unreachable, the 5GC may retrieve and/or modify the copy of the subscriber information that is stored in the FOF. In some examples, the FOF may update the CHF with any changes to the copy of the subscriber information that occurred while the CHF was offline. Thus, the 5GC may continue to enforce policies associated with the subscriber and track subscriber usage even when the CHF is unreachable.

Various implementations described herein are directed to specific improvements in the field of telecommunications. For example, implementations of the FOF described within this disclosure enable a telecommunications network to track subscriber usage and implement subscriber-specific policies even when a CHF cannot be reached. Accordingly, interruptions of the CHF may not interrupt charging policies implemented by the network. From a user perspective, outages of the CHF may be invisible to the subscriber, and therefore interruptions to sessions may be avoided.

Implementations of the present disclosure will now be described with reference to the accompanying figures.

<FIG> illustrates an example network environment <NUM> for providing CHF fallback. In various implementations, a session associated with a subscriber device <NUM> may be set up. According to some examples, the subscriber device <NUM> may request that the session be initiated. In some cases, an external device requests the session with the subscriber device <NUM>. The subscriber device <NUM> may be a user equipment (UE). The terms "UE," "user device," "wireless communication device," "wireless device," "communication device," "mobile device," and "client device," can be used interchangeably to describe any UE that is capable of transmitting/receiving data wirelessly using any suitable wireless communications/data technology, protocol, or standard, such as Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (EVDO), Long Term Evolution (LTE), Advanced LTE (LTE+), New Radio (NR), Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiple Access (OFDM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), Voice over IP (VoIP), VoLTE, Institute of Electrical and Electronics Engineers' (IEEE) <NUM>. 1x protocols, WiMAX, Wi-Fi, Data Over Cable Service Interface Specification (DOCSIS), digital subscriber line (DSL), CBRS, and/or any future IP-based network technology or evolution of an existing Internet Protocol (IP)-based network technology.

Examples of UEs can include, but are not limited to, smart phones, mobile phones, cell phones, tablet computers, portable computers, laptop computers, personal digital assistants (PDAs), electronic book devices, or any other portable electronic devices that can generate, request, receive, transmit, or exchange voice, video, and/or digital data over a network. Additional examples of UEs include, but are not limited to, smart devices such as televisions, refrigerators, washing machines, dryers, smart mirrors, coffee machines, lights, lamps, temperature sensors, leak sensors, water sensors, electricity meters, parking sensors, music players, headphones, or any other electronic appliances that can generate, request, receive, transmit, or exchange voice, video, and/or digital data over a network.

As used herein, the term "session," and its equivalents, can refer to a transmission of data between two endpoints or nodes. A session may include a unidirectional or bidirectional data flow. Examples of sessions include voice calls, internet browsing downloads, and the like. For example, the session may include data transmitted between the subscriber device <NUM> and an external device, such as an external UE or a server. The data transmitted in the session may be associated with one or more particular <NUM> Quality of Service Identifiers (5QIs), guaranteed bit rate (GBR) data, data associated with greater than a threshold priority, data associated with less than a threshold packet delay budget, or the like. The term "GBR data," or its equivalents, can refer to a designation for data that are delivered via a guaranteed bandwidth or bit rate. GBR data may be Quality of Service (QoS)-sensitive data. For example, GBR data may include any of conversational voice data, conversational video (live streaming) data, real time gaming data, Vehicle-to-X (V2X) data, electricity distribution data, process automation (monitoring) data, non-conversational video (buffered streaming) data, mission critical user plane Push to Talk (PTT) voice data, non-mission-critical user plane PTT voice data, mission critical video user plane data, and certain V2X message data. In other examples, GBR data may include different types of QoS-sensitive data.

In some cases, the subscriber device <NUM> may initiate the session by transmitting a signal requesting the session to a Radio Access Network (RAN) <NUM>. In various examples, the subscriber device <NUM> may transmit the request over one or more wireless resources. The terms "RAN," "base station," "access point (AP)," or their equivalents, can refer to one or more devices that can transmit and/or receive wireless services to and from one or more UEs in a coverage area. For example, a RAN can be implemented as a variety of technologies to provide wired and/or wireless access to the network, as discussed herein. In some instances, the RAN <NUM> can include a 3GPP RAN, such a GSM/EDGE RAN (GERAN), a Universal Terrestrial RAN (UTRAN), or an evolved UTRAN (E-UTRAN), or alternatively, a "non-3GPP" RAN, such as a WI-FI RAN, or another type of wireless local area network (WLAN) that is based on the Institute of Electrical and Electronics Engineers (IEEE) <NUM> standards. Further, a base station can include any number and type of transceivers and/or base stations representing any number and type of macrocells, microcells, picocells, or femtocells, for example, with any type or amount of overlapping coverage or mutually exclusive coverage. For example, the subscriber device <NUM> may transmit the signal wirelessly to the RAN <NUM>. The signal may initiate service usage of the subscriber device <NUM>.

In some instances, the RAN <NUM> utilizes wireless resources specified in the <NUM> New Radio (NR) standard, as defined by 3GPP. In certain implementations, the base station <NUM> can transmit and receive communications over frequency resources including "millimeter wave" bands including, but not limited to <NUM>, <NUM>, <NUM>, <NUM>, and the like. In some embodiments, the RAN <NUM> can be, or at least include a gNodeB.

In addition, the RAN <NUM> may utilize other types of wireless resources. For example, the RAN <NUM> may utilize a wireless band including frequency resources in at least one of a Citizens Broadband Radio Service (CBRS) band (e.g., a <NUM>-<NUM> band), a Long Term Evolution (LTE) Band <NUM> (e.g., a <NUM> band), an LTE Band <NUM> (e.g., <NUM>), and the like. In some instances, the frequency resources can include, but are not limited to, LTE Band <NUM> (e.g., <NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM> GHz), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), LTE Band <NUM> (<NUM>), and LTE Band <NUM> (<NUM>). Although referred to in the context of LTE bands, it can be understood that the base station may utilize the frequency resources discussed herein in the context of any <NUM> embodiments.

In some embodiments, the RAN <NUM> is part of a Non-Standalone (NSA) architecture and/or a Standalone (SA) architecture. In an NSA architecture, the RAN <NUM> may be coordinate with an LTE base station (not illustrated), and/or may relay services between devices in the cell <NUM> and an LTE core network (e.g., an Evolved Packet Core (EPC), not illustrated). In an SA architecture, the RAN <NUM> may relay services between devices in the cell and a <NUM> Core (5GC) <NUM>.

In various implementations, the RAN <NUM> may include one or more devices configured to transmit and/or receive data wirelessly over one or more wireless resources within a cell region (also referred to as a "cell"). The cell region may refer to a geographical region that includes the RAN <NUM>. The subscriber device <NUM> may be located within the cell region. For example, in some examples, the RAN <NUM> may include an eNodeB, a gNodeB, or any combination thereof.

The RAN <NUM> may be configured to relay communications between one or more external networks (e.g., the 5GC <NUM>) and the devices located in the cell of the RAN <NUM>, such as the subscriber device <NUM>. Based on the signal from the subscriber device <NUM>, the RAN <NUM> may forward a request to set up the session to the 5GC <NUM>. In particular, the request from the RAN <NUM> may be received by an Access and Mobility Management Function (AMF) <NUM>. The AMF <NUM> may be implemented in hardware and/or software. In general, the AMF can be implemented as a network function including functionality to provide UE-based authentication, authorization, mobility management, etc., to various UEs, such as the subscriber device <NUM>. In some instances, the AMF <NUM> can include functionality to terminate a RAN control plane interface for the RAN <NUM>. In some instances, the AMF <NUM> can include functionality to perform registration management of the subscriber device <NUM> in the RAN <NUM> and/or 5GC <NUM>, connection management, reachability management, mobility management, access authentication, access authorization, security anchor functionality (e.g., receiving and/or transmitting security keys during registration/authorization), and the like.

The AMF <NUM> is configured to select a Session Management Function (SMF) <NUM> for managing a context of the session associated with the subscriber device <NUM>. The SMF <NUM> may be implemented in hardware and/or software. In general, the SMF <NUM> can be implemented as a network function including functionality to manage communication sessions by and between UEs (such as the subscriber device <NUM>) and/or to provide IP addresses to the UEs. In some implementations, the SMF <NUM> may further access subscriber information in order to manage the sessions associated with the 5GC <NUM>.

The 5GC <NUM> further includes a Policy Control Function (PCF) <NUM>. The PCF <NUM> may be implemented in hardware and/or software. In general, the PCF <NUM> can be implemented as a network function including functionality to support unified policy framework to govern network behavior, provide policy rules to control plane functions and/or enforce such rules, and/or implement a front-end to access subscriber information relevant for policy decisions in a data repository.

In various cases, the subscriber information accessed by the SMF <NUM> and/or the PCF <NUM> is stored in a charging function (CHF) <NUM>. The CHF <NUM> may be implemented in hardware and/or software. In general, the CHF <NUM> provides an integrated charging system that controls message commands, chargeable events, and charging-related subscriber information. In particular, the CHF <NUM> implements data connectivity charging for the SMF <NUM> and provides spending limit control functionalities for the PCF <NUM>. To implement these and other functions, the CHF <NUM> stores subscriber information associated with multiple subscribers (e.g., users, account holders, etc.) of the 5GC <NUM>. For example, the CHF <NUM> stores subscriber information associated with a user of the subscriber device <NUM>. In particular implementations, the CHF <NUM> includes one or more databases that store the subscriber information. Although not illustrated in <FIG>, in some implementations, the CHF may include and/or be further connected to a rating function (RF), an account balance management function (ABMF), and a charging gateway function (CGF).

In various examples, the CHF <NUM> interacts with an external billing system <NUM>. The external billing system <NUM> may be implemented in hardware and/or software, and may be outside of the 5GC <NUM>. Although not illustrated in <FIG>, in some cases, the CGF may be connected to the billing system <NUM>. The billing system <NUM> may be configured to implement subscriber policies on behalf of a carrier. As used herein, the term "carrier," and its equivalents, may refer to an organization and/or system responsible for administering a network. In some cases, subscribers may enroll in various subscriber plans offered by the carrier. The subscriber plans, for example, may be associated with usage limits (e.g., data limits, allowed services, etc.) and/or monetary charges for usage of the 5GC <NUM>, such as subscription fees (e.g., to be paid by the subscribers quarterly, monthly, weekly, biweekly, etc.) and/or overage charges (e.g., to be paid if subscribers exceed certain limits). According to some cases, the limits associated with the subscriber plans are reset periodically, such as monthly, biweekly, weekly, etc. For instance, the subscriber of the subscriber device <NUM> may be allotted <NUM> units of data that can be delivered using the 5GC <NUM> per month. The billing system <NUM> may transmit information to the CHF <NUM> that is indicative of the subscriber plans. In some implementations, the billing system <NUM> may transmit the information periodically (e.g., when the limits are reset, such as the end of every month), in response to events (e.g., when the subscriber changes their subscriber plan), or a combination thereof. The CHF <NUM> may modify the subscriber information stored in the CHF <NUM> based on the information from the billing system <NUM>.

As used herein, the term "subscriber information," and its equivalents, may refer to data indicative of limits on usage of a network by a subscriber and/or usage of the network by the subscriber. The subscriber information stored in the CHF <NUM>, for instance, may include an amount and/or type of services that the subscriber is permitted to transmit and/or receive using the 5GC <NUM> in accordance with the subscriber's plan. In some examples, the subscriber information may indicate a remaining amount of services and/or a total amount of services that the subscriber can transmit and/or receive using the 5GC <NUM>. For instance, the amount of services may be an amount of data (e.g., in gigabytes (GB) or some other data measurement) of data traversing the 5GC <NUM>, a number of sessions delivered using the 5GC <NUM>, or the like. In various implementations, the type of services may include at least one of a QoS of the services (e.g., a <NUM> Quality Indicator (5QI) of the services), a latency (e.g., a maximum allowed latency) of the services, a bandwidth (e.g., uplink and/or downlink) allotted to the services, or a slice type (SST) of the services. In some cases, the subscriber information may indicate whether the subscriber is permitted to transmit and/or receive GBR services using the 5GC <NUM>.

According to some implementations, the subscriber information may indicate usage-based limits and/or surcharges associated with the subscriber. For example, the subscriber information may indicate that the subscriber device <NUM> is allowed to transmit and/or receive an amount and/or type of services when the subscriber device <NUM> is located in a certain geographical region (e.g., a cell area of the RAN <NUM>), but that the subscriber device <NUM> is allowed to transmit and/or receive a different amount and/or type of services when the subscriber device <NUM> is located outside of the certain geographical region (e.g., in a roaming region). In some cases, the subscriber information may limit an amount and/or type of services that the subscriber device <NUM> is permitted to transmit and/or receive using the 5GC <NUM>. In some instances, the subscriber information may indicate that the subscriber incurs additional charges (e.g., surcharges) if the subscriber device <NUM> transmits and/or receives greater than a threshold amount, or one or more specific types, of services using the 5GC <NUM>.

In some cases, the 5GC <NUM> may implement quota management for the subscriber device <NUM> using the CHF <NUM>. For example, the subscriber device <NUM> may be associated with a threshold amount of services (e.g., a threshold number of sessions, a threshold amount of data, etc.) that the subscriber device <NUM> is allowed to consume. The CHF <NUM> may store subscriber information including an indication of the threshold associated with the subscriber device <NUM>. In some cases, the CHF <NUM> may be configured to track an amount of services (e.g., a number of sessions, an amount of data transmitted to and/or from the subscriber device <NUM>, etc.) that the subscriber device <NUM> consumes.

In particular examples, the subscriber information stored in the CHF <NUM> may include one or more policy counters. As used herein, the term "policy counter," and its equivalents, may refer to a metric that tracks an amount of network resources utilized by a subscriber device, such as an amount of data transmitted and/or received by the subscriber device over a network, an amount of sessions (e.g., voice calls, text messages, etc.) that the subscriber has engaged in over the network, and the like. In various examples, a policy counter associated with a subscriber device is periodically reset, such as at the end of a billing period associated with the subscriber device. The CHF <NUM> may be configured to store subscriber information including one or more policy counters associated with the subscriber device <NUM>.

In various examples, the subscriber information stored in the CHF <NUM> and associated with the subscriber device <NUM> may further include at least one identifier of the subscriber and/or the subscriber device <NUM>. For instance, the subscriber information may indicate, for example, at least one of a Subscription Permanent Identifier (SUPI) associated with the subscriber, an identifier of the session requested by the subscriber device <NUM>, a type of the session requested by the subscriber device <NUM>, a Data Network Name (DNN) associated with the subscriber device <NUM>, Single-Network Slice Selection Assistance Information (S-NSSAI) associated with the subscriber device <NUM>, a Generic Public Subscriber Identifier (GPSI) associated with the subscriber device <NUM>, an Internal Group Identifier (IGI) associated with the subscriber device <NUM>, an access type, an Internet Protocol (IP) address (e.g., an IP address prefix) of the subscriber device <NUM>, a Permanent Equipment Identifier (PEI) associated with the subscriber device <NUM>, a location of the subscriber device <NUM> (e.g., a time zone), a serving network of the subscriber device <NUM>, or any combination thereof. In some cases, the CHF <NUM> stores the subscriber information in an entry of a database. The CHF <NUM> may store multiple entries corresponding to multiple subscribers of the 5GC <NUM>. For example, the database may be indexed by subscriber and/or subscriber device identifier, such that the CHF <NUM> may be able to efficiently identify the entry associated with the subscriber and/or subscriber device <NUM> based on a request specifying an identifier of the subscriber and/or subscriber device <NUM>.

The billing system <NUM> may interact with the CHF <NUM> based on the subscriber information. For example, the billing system <NUM> may transmit a message to the CHF <NUM> that causes the CHF <NUM> to store and/or modify the subscriber information. In some cases, the billing system <NUM> may cause the CHF <NUM> to reset the subscriber information when a billing period begins. For example, if the subscriber information indicates a remaining amount of data that is allocated to the subscriber, the remaining amount of data may be reset to an original amount at the beginning of the billing period. In addition, the CHF <NUM> may transmit a message indicating the subscriber information to the billing system <NUM>. For instance, if the subscriber information indicates that the subscriber has incurred a surcharge, the CHF <NUM> may inform the billing system <NUM> of the surcharge. The billing system <NUM> may generate or may be used to generate a bill for the surcharge that is addressed to the subscriber. Accordingly, the carrier managing the billing system <NUM> may monetize and/or limit usage of the 5GC <NUM> by the subscriber device <NUM>.

In addition, the SMF <NUM> and/or the PCF <NUM> may send requests for the subscriber information from the CHF <NUM>. In some cases, the SMF <NUM> and/or the PCF <NUM> may send requests to modify the subscriber information stored in the CHF <NUM>. For example, the SMF <NUM> may transmit, to the CHF <NUM>, a request to update the subscriber information associated with the subscriber device <NUM>, based on the session. In various implementations, the CHF <NUM> may update the subscriber information associated with the subscriber device <NUM> in the database(s) of the CHF <NUM> based on the request from the SMF <NUM>. For instance, the request may indicate usage of the 5GC <NUM> by the subscriber device <NUM> and the CHF <NUM> may update the subscriber information based on the usage of the 5GC <NUM> by the subscriber device <NUM>. In addition, the CHF <NUM> may return a response to the request indicating that the charging data has been updated.

In addition, the SMF <NUM> may request subscriber information from the CHF <NUM>. For example, the SMF <NUM> may request a type of services (e.g., 5QI services) that the subscriber device <NUM> is allowed to transmit and/or receive using the 5GC <NUM>. In various implementations, the SMF <NUM> may select a User Plane Function (UPF) <NUM> for the session based on the subscriber information. Furthermore, the SMF <NUM> may provision policy and/or threshold rules for usage control by the UPF <NUM> of the requested session. In some cases, the SMF <NUM> may cause the UPF <NUM> to deliver requested 5QI services (e.g., at a particular maximum latency associated with the 5QI services) if the subscriber information indicates that the 5QI services are permitted for the subscriber. For example, the SMF <NUM> may cause the UPF <NUM> to enforce a particular uplink and/or downlink rate for the services.

In general, the UPF <NUM> can be implemented as a network function including functionality to control data transfer between the subscriber device <NUM> and the various components of the environment <NUM>. In some instances, the UPF <NUM> can include functionality to act as an anchor point for Radio Access Technology (RAT) handover (e.g., inter and intra), external protocol data unit (PDU) session point of interconnect to an external network (e.g., the Internet), packet routing and forwarding, packet inspection and user plane portion of policy rule enforcement, traffic usage reporting, traffic routing, QoS handling for user plane (e.g., packet filtering, gating, uplink/downlink rate enforcement), uplink traffic verification, transport level packet marking in the uplink and downlink, downlink packet buffering and downlink data notification triggering, and the like. As can be understood in the context of this disclosure, the UPF <NUM> may be one or more UPFs, which are associated with the subscriber device <NUM>.

The PCF <NUM> may also rely on the CHF <NUM> to perform various functions. In some implementations, the PCF <NUM> may request and/or modify subscriber information stored in the CHF <NUM>. In some examples, during session setup, the PCF <NUM> may interface with a User Data Repository (UDR) in the 5GC <NUM> (not illustrated) to identify a profile associated with the subscriber device <NUM>. The profile may specify one or more policy rules associated with the subscriber device <NUM>. The PCF <NUM> may be configured to make a policy decision about the session based on the profile of the subscriber device <NUM>, the type of services being requested in the session, and/or other features of the session. In some examples, the PCF <NUM> may determine the policy decision by interfacing with the CHF <NUM>. For instance, the PCF <NUM> may determine the policy decision based on the subscriber information (e.g., policy counter(s)) stored in the CHF <NUM>. In some cases, the PCF <NUM> may transmit, to the CHF <NUM>, a request for subscriber information. In some cases, the request for the subscriber information may specify a particular type of policy counter stored by the CHF <NUM>. In various implementations, the CHF <NUM> may refer to the database(s) within the CHF <NUM> to identify the policy counters associated with the subscriber device <NUM>. The CHF <NUM> may return an indication of the requested policy counter(s) to the PCF <NUM>. For example, the PCF <NUM> may receive a policy counter indicating that the subscriber device <NUM> has transmitted and/or received five units of data during a current time period (e.g., billing period). The PCF <NUM> may compare the policy counter to subscriber information associated with the subscriber device <NUM>. For example, the PCF <NUM> may determine that the five units of data is less than the <NUM> units of data allotted to the subscriber device during the current time period. Accordingly, the PCF <NUM> may make a policy decision that the session is to be allowed and allocated particular resources within the 5GC <NUM>. The PCF <NUM> may indicate (e.g., to the SMF <NUM>), the policy decision associated with the session and/or the subscriber device <NUM>.

In addition, the CHF <NUM> may update the database(s) based on the session requested by the subscriber device <NUM>. For example, the SMF <NUM> and/or the PCF <NUM> may transmit a request to the CHF <NUM> for adjusting subscriber information (e.g., policy counter(s)) associated with an amount of data transmitted and/or received by the subscriber device <NUM> based on the amount of data transmitted and/or received by the subscriber device <NUM> in the session. In some cases, the CHF <NUM> may adjust (e.g., increase) subscriber information associated with a number of sessions associated with the subscriber device <NUM> based on the requested session. Accordingly, the CHF <NUM> may ensure that the subscriber information is updated based on the session.

In some examples, the SMF <NUM> and/or the PCF <NUM> may rely on the subscriber information stored in the CHF <NUM> to manage existing sessions associated with the subscriber device <NUM>. For example, the subscriber information may indicate that the subscriber device <NUM> has reached a limit (e.g., a data limit) of the subscriber's plan with the carrier during the session. The SMF <NUM> and/or the PCF <NUM> may enforce the limit during the session. For example, the SMF <NUM> may cause the UPF <NUM> to throttle a transmission rate of data in the session based on the exceeded limit.

In the example illustrated in <FIG>, the UPF <NUM> may be configured to deliver data in the session to or from a Data Network (DN) <NUM>. Examples of the DN <NUM> include, for instance, a wide area network (WAN), such as the Internet. In some instances, DN <NUM> may include or be connected to an IP Multimedia Subsystem (IMS) core (sometimes referred to as an "IMS core network," an "IMS network," or an "IM CN Subsystem"). IMS is an architectural framework defined by 3GPP for delivering Internet Protocol (IP) multimedia to a device, such as the subscriber device <NUM>. The IMS core can be maintained and/or operated by one or more service providers, such as one or more wireless carriers ("carriers"), that provide IMS-based services to a user who is associated with the device. For example, a service provider can offer multimedia telephony services that allow a user to call or message other users via the IMS core using their device. A user can also utilize an associated device to receive, provide, or otherwise interact with various different IMS-based services by accessing the IMS core. It is to be appreciated that any number of base stations, such as base station <NUM>, and/or IMS nodes can be associated with the IMS network.

An operator (e.g., a carrier) of the IMS core can offer any type of IMS-based service, such as, telephony services, emergency services (e.g., Enhanced <NUM> (E911)), gaming services, instant messaging services, presence services, video conferencing services, social networking and sharing services, location-based services, push-to-talk services, and so on. In order to access these services (e.g., telephony services), a device is configured to request establishment of a communication session. In the case of telephony services, the communication session can comprise a call (e.g., a voice-based communication session, such as a Voice Over LTE (VoLTE) call, or a Wi-Fi call). The RAN <NUM> may be configured to transmit the data in the session to and/or from the subscriber device <NUM> over one or more wireless resources. Accordingly, the session may be established between the subscriber device <NUM> and the DN <NUM>. For instance, the DN <NUM> may include a server that transmits data to and/or receives data from the subscriber device <NUM> via the UPF <NUM>.

In various implementations, the CHF <NUM> may be relied upon by the SMF <NUM> and/or the PCF <NUM> to set up sessions for the subscriber device <NUM> and/or manage existing sessions by the subscriber device <NUM>. In certain cases, however, at least a portion of the CHF <NUM> may be unreachable by the SMF <NUM> and/or the PCF <NUM>. For example, a first interface <NUM> connecting the SMF <NUM> and/or the PCF <NUM> to the CHF <NUM> may become disconnected, such that the CHF <NUM> may be unable to receive a request transmitted from the SMF <NUM> and/or the PCF <NUM>. Although not illustrated in <FIG>, there may be two separate first interfaces <NUM> respectively connecting the SMF <NUM> and the PCF <NUM> to the CHF <NUM>. In some examples, a front-end of the CHF <NUM> (e.g., a load balancer) may have an outage, which may prevent the SMF <NUM> and/or the PCF <NUM> from reaching the CHF <NUM>. In some implementations, another component of the CHF <NUM> is experiencing an outage, such that the CHF <NUM> cannot access the database(s) storing the subscriber information associated with the subscriber device <NUM>.

In various implementations of the present disclosure, a Fail Open Function (FOF) <NUM> is configured to accommodate requests from the SMF <NUM> and/or the PCF <NUM> when at least a portion of the CHF <NUM> is reachable. The FOF <NUM> may include one or more databases configured to store a copy of the policy counter(s) associated with the subscriber device <NUM>. The FOF <NUM> may be implemented in software and/or hardware, but may be implemented in one or more different devices than the device(s) implementing the CHF <NUM>. Thus, even if there is an outage of hardware implementing at least a portion of the CHF <NUM>, the FOF <NUM> may nevertheless continue functioning uninterrupted. Furthermore, the SMF <NUM> and/or the PCF <NUM> may be connected to the FOF <NUM> via a second interface <NUM>, wherein the first interface <NUM> is different than the second interface <NUM>. Thus, even if an outage in the first interface <NUM> prevents the SMF <NUM> and/or the PCF <NUM> from communicating with the CHF <NUM>, the SMF <NUM> and/or the PCF <NUM> may still be able to communicate with the FOF <NUM> over the second interface <NUM>.

In some cases, the SMF <NUM> and/or the PCF <NUM> may determine that it is unable to reach the CHF <NUM>. For example, the SMF <NUM> and/or the PCF <NUM> may determine that greater than a threshold amount of time after transmitting the request towards the CHF <NUM> has passed without receiving a response from the CHF <NUM>. In some cases, the CHF <NUM> may return an error message to the SMF <NUM> and/or PCF <NUM>. Upon determining that the CHF <NUM> is unreachable, the SMF <NUM> and/or the PCF <NUM> may transmit the request to the FOF <NUM>.

In some cases, like the CHF <NUM>, the FOF <NUM> includes at least one database storing a copy of the subscriber information. Thus, the FOF <NUM> may refer to its own copy of the subscriber information to return the requested subscriber information to the SMF <NUM> and/or the PCF <NUM>. Further, the FOF <NUM> may modify the subscriber information in accordance with a request from the SMF <NUM> and/or the PCF <NUM>. Thus, the FOF <NUM> may at least temporarily be a substitute for the unreachable CHF <NUM>.

In some implementations, at least a portion of the CHF <NUM> is functioning and communicates with the FOF <NUM> over a third interface <NUM>. For example, in some cases, a front-end of the CHF <NUM> is experiencing an outage, such that the SMF <NUM> and/or the PCF <NUM> may be unable to transmit the request to the CHF <NUM>. However, the database(s) of the CHF <NUM> may remain functioning. In some cases, the SMF <NUM> and/or the PCF <NUM> transmits the request to the FOF <NUM>, which may transmit a message to a functioning portion of the CHF <NUM> over the third interface <NUM>. The functioning portion of the CHF <NUM> may retrieve and/or update the subscriber information associated with the subscriber device <NUM> based on the request. The functioning portion of the CHF <NUM> may return a response (e.g., including the requested subscriber information and/or an indication that the subscriber information has been updated) to the FOF <NUM> over the third interface <NUM>, which can forward the response the SMF <NUM> and/or the PCF <NUM> for further processing. Thus, in some cases, the FOF <NUM> may refrain from accessing the copy of the subscriber information stored in the database(s) of the FOF <NUM>.

In some cases, the front-end of the CHF <NUM> is intact, but the database(s) of the CHF <NUM> may be experiencing an outage. In some of these implementations, the SMF <NUM> and/or the PCF <NUM> may transmit the request to the front-end of the CHF <NUM> over the first interface <NUM>. The CHF <NUM> may then forward the request to the FOF <NUM> over the third interface <NUM>. Upon receiving the request from the CHF <NUM>, the FOF <NUM> may access and/or update the subscriber information in the database(s) of the FOF <NUM> based on the request. The FOF <NUM> may further generate a response based on the accessed and/or updated subscriber information and send the response to the CHF <NUM>. Thus, in some cases, the outage of the database(s) of the CHF <NUM> is invisible to the SMF <NUM> and/or the PCF <NUM>.

According to various implementations, the databases of the CHF <NUM> and the FOF <NUM> can be reconciled. For example, when operating normally, the CHF <NUM> may transmit periodic (e.g., once every day, once every two days, once every week, or the like) updates of the subscriber information stored within the database(s) of the CHF <NUM> to the FOF <NUM> over the third interface <NUM>. The FOF <NUM> may therefore update the subscriber information within the database(s) of the FOF <NUM> accordingly.

Furthermore, the FOF <NUM> may update the CHF <NUM> with any changes to the database(s) of the FOF <NUM> that have occurred while the database(s) of the CHF <NUM> were temporarily unreachable. For instance, upon determining that the CHF <NUM> has become reachable over the third interface <NUM>, the FOF <NUM> may transmit indications of the subscriber information stored in the database(s) of the FOF <NUM>, which may have been updated while the database(s) of the CHF <NUM> was unreachable. Accordingly, the CHF <NUM> may update the database(s) of the CHF <NUM> based on subscriber activity that occurred while the database(s) were unreachable.

<FIG> illustrates an example environment <NUM> illustrating CHF fallback. The environment <NUM> includes the CHF <NUM>, the FOF <NUM>, the first interface <NUM>, the second interface <NUM>, and the third interface <NUM> described above with reference to <FIG>. In addition, the environment <NUM> includes a connected function <NUM>, which may be the SMF <NUM> and/or the PCF <NUM> described above with respect to <FIG>.

In various implementations, the connected function <NUM> may transmit a request based on a subscriber session (e.g., a session associated with the subscriber device <NUM> described above with reference to <FIG>) by communicating with the CHF <NUM> and/or the FOF <NUM>. The request may be to access and/or modify subscriber information associated with the session (e.g., subscriber information associated with the subscriber device <NUM>).

In examples in which the CHF <NUM> is reachable and online, the connected function <NUM> may transmit the request to a CHF front-end <NUM> over the first interface <NUM>. The CHF front-end <NUM> may be implemented in software and/or hardware. For example, the CHF front-end <NUM> may be a virtual machine (VM) operating on at least one server implementing the CHF <NUM>. The CHF front-end <NUM> may be configured to receive communications over the first interface <NUM> from entities outside of the CHF <NUM>. In various cases, the CHF front-end <NUM> may be configured to select a charging control node <NUM> to handle the request.

The selected charging control node <NUM> may be one of multiple charging control nodes included in the CHF <NUM>. The charging control node <NUM> may be implemented in software and/or hardware. For example, the charging control node <NUM> may be a VM operating on at least one server implementing the CHF <NUM>. In various implementations, the charging control node <NUM> may be configured to retrieve and/or modify subscriber information stored in a subscriber account database <NUM> included in a subscriber account database & rating function <NUM>. For example, the charging control node <NUM> may provide requested subscriber information to the connected function <NUM> and/or may cause the subscriber information to be modified based on the request.

The subscriber account database & rating function <NUM> may be implemented in software and/or hardware. For example, the subscriber account database & rating function <NUM> may be include a VM within the CHF <NUM>. Upon retrieving the data and/or modifying the data, the charging control node <NUM> may generate and return a response to the CHF front-end <NUM>, which may return the response to the connected function <NUM> via the first interface <NUM>. The response, for example, may include the requested subscriber information and/or indicate that the subscriber information has been modified in accordance with the request.

However, in particular implementations, the first interface <NUM> and/or at least a portion of the CHF <NUM> may be unreachable and/or nonfunctional. For example, the first interface <NUM> may be interrupted, but the CHF <NUM> may nevertheless be functional. In various implementations, the connected function <NUM> may determine that the first interface <NUM> is interrupted. For instance, the connected function <NUM> may attempt to transmit the request over the first interface <NUM>, but may determine that the connected function <NUM> has not received the response to the request within a threshold time period of transmitting the request. Once the connected function <NUM> determines that the CHF <NUM> is unreachable, the connected function <NUM> may communicate with the FOF <NUM>. For example, the connected function <NUM> may transmit the request over the second interface <NUM> to an FOF load balancer <NUM> within the FOF <NUM>. In some examples, the CHF <NUM> may be implemented by at least one first server (e.g., in at least one first data center), and the FOF <NUM> may be implemented by at least one second server (e.g., in at least one second data center), wherein the first server(s) are different than the second server(s) (and the first data center(s) are different than the second data center(s)).

The load balancer <NUM> may receive the request from the connected function <NUM>. The load balancer <NUM> may be implemented in software and/or hardware. For example, the load balancer <NUM> may include a VM operating on at least one server implementing the FOF <NUM>. The load balancer <NUM> may be configured to distribute various requests from the connected function <NUM>, or other connected functions (e.g., other SMFs and/or PCFs) within the network environment <NUM>, to multiple FOF front-ends within the FOF <NUM>. For example, the load balancer <NUM> may evenly distribute the requests between the multiple FOF front-ends. In various cases, the load balancer <NUM> is configured to select an FOF front-end <NUM> for the request from the connected function <NUM>. The load balancer <NUM> may forward the request to the selected FOF front-end <NUM>. The FOF front-end <NUM> may be implemented in hardware and/or software. For example, the FOF front-end <NUM> may be include a VM within the FOF <NUM>.

In various cases, the FOF front-end <NUM> transmits the request to a lookup function <NUM>, which is part of an offline database function <NUM> within the FOF <NUM>. The lookup function <NUM> may be implemented in hardware and/or software. For example, the lookup function <NUM> may include a VM operating on at least one server implementing the FOF <NUM>. In various examples, the lookup function <NUM> may be configured to determine whether to process requests within the FOF <NUM> or whether to forward requests to the CHF <NUM>. For example, the lookup function <NUM> may interact with an FOF control node <NUM> and/or an activity updater <NUM> to determine whether the CHF <NUM> is reachable via the third interface <NUM>. The FOF control node <NUM> and the activity updater <NUM> may respectively be implemented in hardware and/or software. For example, the FOF control node <NUM> and/or the activity updater <NUM> may be implemented in one or more VMs hosted by the FOF <NUM>. For example, the FOF control node <NUM> may transmit a signal to the lookup function <NUM> indicating that the charging control node <NUM> of the CHF <NUM> is reachable via the third interface <NUM>. Similarly, activity updater <NUM> may transmit a signal to the lookup function <NUM> indicating that the subscriber account database & rating function <NUM> is reachable via the third interface <NUM>. Upon receiving the request, the lookup function <NUM> may transmit the request to the FOF control node <NUM> and/or the activity updater <NUM> based on the connectivity of the CHF <NUM> and the FOF <NUM> over the third interface <NUM>.

In various implementations, the lookup function <NUM> may determine that the charging control node <NUM> is reachable by the FOF control node <NUM> via the third interface <NUM>. Thus, the lookup function <NUM> may forward the request to the FOF control node <NUM>, which may provide the request to the charging control node <NUM> over the third interface <NUM>. Based on the request, the charging control node <NUM> may cause retrieval and/or modification of the subscriber information stored in the subscriber account database <NUM>, and may return a response to the FOF control node <NUM> over the third interface <NUM>. The FOF <NUM> may return the response to the connected function <NUM> (e.g., via the lookup function <NUM>, the FOF front-end <NUM>, and/or the FOF load balancer <NUM>). Thus, even if there is an outage in the first interface <NUM> and/or the CHF front-end <NUM>, the FOF <NUM> may enable access and/or modification of the subscriber information in the subscriber account database <NUM>.

In some implementations, the FOF control node <NUM> indicates, to the lookup function <NUM>, that the charging control node <NUM> is unreachable via the third interface <NUM>. However, the activity updater <NUM> may indicate, to the lookup function <NUM>, that the subscriber account database & rating function <NUM> is reachable via the third interface <NUM>. In such cases, the lookup function <NUM> may transmit the request to the activity updater <NUM>, which may forward the request to the subscriber account database & rating function <NUM>. The subscriber account database & rating function <NUM> may access and/or modify the copy of subscriber information in accordance with the request. The subscriber account database & rating function <NUM> may generate a response indicating the requested and/or modified subscriber information. The subscriber account database & rating function <NUM> may return the response to the connected function <NUM> via the FOF <NUM>. For example, the response may be transmitted over the third interface <NUM> to the activity updater <NUM>, to the lookup function <NUM>, to the FOF front-end <NUM>, and to the FOF load balancer <NUM>, which may transmit the response over the second interface <NUM> to the connected function <NUM>.

In some cases, however, the FOF <NUM> may determine that the CHF <NUM> is unreachable. For example, the third interface <NUM> may be interrupted and/or the CHF <NUM> may be offline. Instead of communicating with the CHF <NUM>, the FOF <NUM> may retrieve and/or modify a copy of the subscriber information stored in an offline account database <NUM>. The FOF <NUM> may return the response to the connected function <NUM> based on accessing and/or modifying the offline account database <NUM>. Accordingly, even if the CHF is offline, the FOF <NUM> may track and/or report ongoing usage and/or subscription info about the session and/or the subscriber device.

In various implementations, the data in the subscriber account database <NUM> and the offline account database <NUM> are reconciled when the third interface <NUM> is intact. For example, the subscriber account database <NUM> within the CHF <NUM> may be modified over time based on changes to subscriber information, billing periods, and the like. The subscriber account database & rating function <NUM>, in various implementations, may transmit updated data (e.g., a copy of at least a portion of the data in the subscriber accounts database <NUM>) to an account updater <NUM> in the FOF <NUM> via the third interface <NUM>. The account updater <NUM> may be implemented in software and/or hardware. For example, the account updater <NUM> may be include a VM within the FOF <NUM>. The account updater <NUM> may update the offline account database <NUM> based on the updated data. In some cases, the subscriber account database & rating function <NUM> transmits updates to the FOF <NUM> about the subscriber account database <NUM> periodically (e.g., once every day, once every <NUM> hours, etc.).

Similarly, FOF <NUM> may update the CHF <NUM> about changes to the offline account database <NUM> that occurred while the CHF <NUM> was temporarily unreachable. For example, the activity updater <NUM> within the FOF <NUM> may be configured to identify when the CHF <NUM> is reachable. Based on determining the CHF <NUM> is reachable, the activity updater <NUM> may cause the lookup function <NUM> to retrieve data stored in the offline account database <NUM>. The retrieved data, for example, includes data that was updated and/or accessed during the outage of the CHF <NUM>. The activity updater <NUM> may transmit the retrieved data to the subscriber account database & rating function <NUM> over the third interface <NUM>. The subscriber account database & rating function <NUM> may update the subscriber account database <NUM> based on the retrieved data. Thus, the subscriber account database <NUM> may be updated based on subscriber activity that occurred while the CHF <NUM> was unreachable and/or offline. In various implementations, the lookup function <NUM>, the offline account database <NUM>, and the activity updater <NUM> may collectively be included in an offline database function <NUM> within the FOF <NUM>.

<FIG> illustrates example signaling <NUM> for accessing and updating a CHF database when the database is reachable but the front-end of the CHF is unreachable. As shown, the signaling <NUM> is between the connected function <NUM>, the CHF front-end <NUM>, the offline database function <NUM>, and the subscriber account database & rating function <NUM>.

The connected function <NUM> may attempt to transmit a request <NUM> to the CHF front-end <NUM>. In some examples, the request <NUM> is for subscriber information associated with a subscriber and/or session. In some cases, the request <NUM> is to change the subscriber information based on the session. The subscriber information may be stored within a database of a CHF that includes the CHF front-end <NUM>. However, in various implementations, the CHF front-end <NUM> may be unreachable. For example, the connected function <NUM> may not receive a response from the CHF front-end <NUM> within a threshold time period after transmitting the request <NUM>. Alternately, the connected function <NUM> may receive an error message from the CHF front-end <NUM>.

Upon determining that the CHF front-end <NUM> is unreachable, the connected function <NUM> may transmit the request <NUM> to the offline account database function <NUM>. Although not pictured in <FIG>, the request <NUM> may be transmitted via an FOF load balancer and an FOF front-end prior to reaching the offline account database function <NUM>. In various implementations, the offline account database function <NUM> may determine that the subscriber account database & rating function <NUM> is reachable. For example, the offline account database function <NUM> may determine that an interface between the FOF and the CHF is intact, that a charging control node is reachable, that the subscriber account database & rating function <NUM> is reachable but the charging control node is unreachable, or the like. The offline account database function <NUM> may forward the request <NUM> to the subscriber account database & rating function <NUM>.

Based on the request <NUM>, the subscriber account database & rating function <NUM> may modify and/or access subscriber account information stored by the subscriber account database & rating function <NUM>. The subscriber account database & rating function <NUM> may generate a response <NUM> based on the modified and/or accessed subscriber account information. The subscriber account database & rating function <NUM> may transmit the response <NUM> back to the connected function <NUM> via the offline account database function <NUM>.

<FIG> illustrates example signaling <NUM> for accommodating requests for subscriber information when the CHF is temporarily unreachable. As shown, the signaling <NUM> is between the connected function <NUM>, the CHF front-end <NUM>, the offline database function <NUM>, and the subscriber account database & rating function <NUM>.

Upon determining that the CHF front-end <NUM> is unreachable, the connected function <NUM> may transmit the request <NUM> to the offline account database function <NUM>. Although not pictured in <FIG>, the request <NUM> may be transmitted via an FOF load balancer and an FOF front-end prior to reaching the offline account database function <NUM>. In various implementations, the offline account database function <NUM> may determine that the subscriber account database & rating function <NUM> is unreachable. For example, the offline account database function <NUM> may determine that an interface between the FOF and the CHF is interrupted, that a charging control node in the CHF is unreachable, that the subscriber account database & rating function <NUM> is unreachable, or the like. Thus, the offline account database function <NUM> may be unable to forward the request <NUM> to the CHF.

Based on the request <NUM>, the offline account database function <NUM> may modify and/or access a copy of subscriber information stored by the offline account database function <NUM>. The offline account database function <NUM> may generate a response <NUM> based on the modified and/or accessed subscriber account information. The offline account database function <NUM> may transmit the response <NUM> back to the connected function <NUM>. For example, the offline account database function <NUM> may transmit the response <NUM> via an FOF front-end and FOF load balancer.

In various implementations, after modifying and/or accessing the copy of the subscriber information, the offline account database function <NUM> may determine that the CHF is reachable. For example, the offline account database function <NUM> may determine that an interface between the FOF and the CHF is intact, that a charging control node within the CHF is reachable, that the subscriber account database & rating function <NUM> is reachable, or a combination thereof. In various implementations, the offline account database function <NUM> may determine that the subscriber account database & rating function <NUM> is reachable by receiving a connection confirmation <NUM> from the subscriber account database & rating function <NUM>. In various cases, the connection confirmation <NUM> can be any message or data that indicates the subscriber account database & rating function <NUM> is reachable. Although <FIG> indicates that the subscriber account database & rating function <NUM> transmits the connection confirmation <NUM>, the connection confirmation <NUM> can be generated and/or transmitted by other elements of the CHF, such as a charging control node.

Based on determining that the subscriber account database & rating function <NUM> is reachable, the offline account database function <NUM> may transmit updated information <NUM> to the subscriber account database & rating function <NUM>. The updated information <NUM> may include or otherwise indicate the copy of the subscriber information that was accessed and/or modified while the subscriber account database & rating function <NUM> was unreachable. For instance, the updated information <NUM> may indicate one or more changes to the copy of the subscriber information that occurred since the subscriber account database & rating function <NUM> was unreachable. Based on the updated information <NUM>, the subscriber account database & rating function <NUM> may update the subscriber information stored within the subscriber account database & rating function <NUM> based on the subscriber activity that occurred while the subscriber account database & rating function <NUM> was unreachable.

<FIG> illustrates an example environment <NUM> including multiple CHFs and FOFs for enhanced redundancy. As shown, the environment <NUM> includes the connected function <NUM> described above with reference to <FIG>. In various implementations, the connected function <NUM> is connected to multiple CHFs including a first CHF <NUM> and a second CHF <NUM>. The first CHF <NUM> and the second CHF <NUM> may be in different regions. For example, the first CHF <NUM> may be in a first region <NUM> and the second CHF <NUM> may be in a second region <NUM>. The first region <NUM> may be defined as a first geographical area and/or at least one first data center. The second region <NUM> may be defined as a second geographical area and/or at least one second geographical area.

The first CHF <NUM> and the second CHF <NUM> may be connected via a Network Repository Function (NRF) <NUM>. Although not illustrated in <FIG>, the NRF <NUM> may be included in the 5GC <NUM>. In general, the NRF <NUM> can be implemented as a network function including functionality to support service discovery (e.g., receive a network function discovery request and provide information associated with the discovered network function instances to a requesting entity). In some instances, the NRF <NUM> can receive utilization information, capability information, etc. from various network functions to provide such utilization information to the other components of a 5GC discussed herein. Further, the NRF <NUM> can select, assign, implement, or otherwise determine network functions to be used in the environment <NUM>. For example, the NRF <NUM> may select the first CHF <NUM> or the second CHF <NUM> for establishing and/or continuing a session.

In some examples, the connected function <NUM> and/or the NRF <NUM> may determine that the first CHF <NUM> is unreachable. Based on this determination, the connected function <NUM> and/or the NRF <NUM> may forward requests to access and/or modify subscriber information to the second CHF <NUM>, rather than the first CHF <NUM>. Thus, in some cases, the second CHF <NUM> may serve as a fallback CHF if the first CHF <NUM> is unreachable.

In various implementations, the first CHF <NUM> and the second CHF <NUM> may be at least partially unreachable. For instance, the NRF <NUM> and/or the connected function <NUM> may determine that the first CHF <NUM> and the second CHF <NUM> are inaccessible. Based on this determination, the connected function <NUM> may transmit requests to a first FOF <NUM> and/or a second FOF <NUM>. The first FOF <NUM> may be within the first region <NUM> and may be connected to the first CHF <NUM>. The second FOF <NUM> may be within the second region <NUM> and may be connected to the second CHF <NUM>. In cases where one of the FOFs <NUM> or <NUM> is unreachable, the connected function <NUM> may provide requests to the other one of the FOFs <NUM> or <NUM>.

<FIG> illustrates an example process <NUM> for establishing and/or managing a session based on charging policies. The process <NUM> may be performed by an entity, such as the SMF <NUM>, the PCF <NUM>, the connected function <NUM>, or any combination thereof.

At <NUM>, the entity receives an indication of a session associated with a subscriber. In some examples, the session is initiated by the subscriber. For example, a device associated with the subscriber (e.g., a "subscriber device") may transmit, to a 5GC including the entity, a request to transmit and/or receive data from an external device using the 5GC. In some implementations, the session is initiated by the external device. For example, the 5GC may receive a request from an external network associated with the external device. In various implementations, the session may include an amount of data transferred between the subscriber device and the external device. In some cases, the data may be associated with a particular type of services, such as GBR services, services associated with a particular 5QI level, services associated with a particular maximum latency, or a combination thereof. In particular cases, the subscriber device may be located in a particular geographic region during the session, and the entity may receive an indication of the geographic region.

At <NUM>, the entity transmits a request to a CHF. The request may be for at least a portion of subscriber information stored in the CHF. For example, the request may be for a limit associated with the type and/or amount of data that the subscriber device may transmit and/or receive using the 5GC. In some cases, the request may be to change at least a portion of the subscriber information stored in the CHF. For instance, the request may be to update one or more policy counters associated with the subscriber based on the session. In various implementations, the request may identify the subscriber. For instance, the request may include an IP address of the subscriber device, a unique identifier of the subscriber, or the like. In some cases, the request may identify an amount and/or type of data that is requested to be transferred in the session. In some instances, the request may indicate the geographic region in which the subscriber device is located.

At <NUM>, the entity determines whether an error message has been received from the CHF. In some implementations, the CHF may itself identify that it is at least partially offline. For example, a front-end of the CHF may determine that one or more charging control nodes in the CHF are unreachable. In various cases, the CHF front-end may generate and transmit an error message to the entity. The error message may indicate that the CHF is at least temporarily unreachable. However, in examples in which the CHF is completely unreachable, the front-end of the CHF may be unable to receive the request from the entity and/or generate the error message.

If the entity determines that the error message has not been received at <NUM>, then the process <NUM> proceeds to <NUM>. At <NUM>, the entity determines whether a response has been received from the CHF. For example, if the CHF is operating without interruptions, the CHF may receive the request and access and/or modify subscriber information stored in the CHF based on the request. In addition, the CHF may generate and transmit (to the entity) a response based on the accessed and/or modified subscriber information.

If the entity determines that the response has been received from the CHF at <NUM>, then the process continues to <NUM>. At <NUM>, the entity establishes and/or continues the session based on the response from the CHF. In various implementations, the entity may select a UPF for the session based on the subscriber information. In some cases, the entity may cause the UPF to enforce certain policies on the data transferred in the session based on the subscriber information. For instance, if the subscriber information indicates that the subscriber is not permitted to receive and/or transmit data associated with a particular 5QI (e.g., URLLC data), then the entity may cause the UPF to deliver data in the session using a different QCI (e.g., at a higher maximum latency than required for URLLC data).

If, on the other hand, the entity determines that the response has not been received from the CHF at <NUM>, then the process continues to <NUM>. At <NUM>, the entity determines whether a threshold time has expired. In cases, for example, where the CHF is completely offline or otherwise unreachable by the entity, the CHF may be unable to receive the request from the entity and/or generate a response to the request. To prevent the entity from waiting for the response, indefinitely, from the CHF, the entity may determine whether the request and/or the response is timed out.

If the entity determines that the threshold time has not expired at <NUM>, then the process returns to <NUM>. However, if the entity determines that the error message has been received from the CHF at <NUM>, or the entity determines that the threshold time has expired at <NUM>, then the process <NUM> continue at <NUM>. At <NUM>, the entity transmits the request to an FOF. The FOF may be different than the CHF. For example, the FOF may be implemented by one or more first computing devices, the CHF may be implemented by one or more second computing devices, and the first computing device(s) may be different than the second computing device(s). In some implementations, the entity may communicate with the FOF over a first communications interface, with the CHF over a second communications interface, and the first communications interface may be different than the second communications interface. Accordingly, the FOF may be reachable even if the CHF is unreachable.

The FOF may store a copy of the subscriber information. In some cases, the FOF may access and/or modify the copy of the subscriber information based on the request from the entity. Furthermore, the FOF may be configured to generate a response based on the accessed and/or modified copy of the subscriber information stored in the FOF. In some implementations, the FOF may be able to reach at least a portion of the CHF over a third communications interface, even though the entity may be unable to reach the CHF. The FOF may forward the request from the entity to the CHF, which may access and/or modify the copy of the subscriber information stored in the CHF. The CHF may generate a response based on the accessed and/or modified subscriber information and return the response to the FOF.

At <NUM>, the entity receives a response from the FOF. The response, for example, may originate from the FOF or the CHF.

At <NUM>, the entity establishes and/or continues the session based on the response from the FOF. For example, the entity may enforce a policy for the policy based on the subscriber information. In some cases, the entity may select a UPF to deliver data in the session based on the subscriber information. In some implementations, the entity may enforce limits (e.g., latency limits, data limits, etc.) on data transferred in the session based on the subscriber information.

<FIG> illustrates a process <NUM> for accommodating requests when a CHF is unreachable and updating the CHF when the CHF becomes reachable. The process <NUM> is performed by an entity, such as the FOF <NUM>, the first FOF <NUM>, the second FOF <NUM>, or any combination thereof.

At <NUM>, the entity may receive subscriber information from a CHF. The subscriber information, in various implementations, may include data indicative of limits on usage of a network by a subscriber and/or usage of the network by the subscriber. For instance, the subscriber information may include an amount and/or type of services that the subscriber is permitted to transmit and/or receive using at least one network (e.g., a 5GC) in accordance with the subscriber's plan. In some examples, the subscriber information may indicate a remaining amount of services and/or a total amount of services that the subscriber can transmit and/or receive using network(s). For instance, the amount of services may be an amount of data (e.g., in gigabytes (GB) or some other data measurement) traversing the network(s), a number of sessions delivered using the network(s), or the like. In various implementations, the type of services may include at least one of a QoS of the services, a latency of the services, a bandwidth allotted to the services, or a slice type (SST) of the services. In some cases, the subscriber information may indicate whether the subscriber is permitted to transmit and/or receive GBR services using the network(s).

According to some implementations, the subscriber information may indicate usage-based limits and/or surcharges associated with the subscriber. For example, the subscriber information may indicate that a device associated with the subscriber is allowed to transmit and/or receive an amount and/or type of services when the device is located in a certain geographical region (e.g., a cell area), but that the device is allowed to transmit and/or receive a different amount and/or type of services when the device is located outside of the certain geographical region (e.g., in a roaming region). In some cases, the subscriber information may limit an amount and/or type of services that the device is permitted to transmit and/or receive using the network(s). In some instances, the subscriber information may indicate that the subscriber incurs additional charges (e.g., surcharges) if the device transmits and/or receives greater than a threshold amount, or one or more specific types, of services using the network(s).

In some cases, the subscriber information may be associated with quota management. For example, the device may be associated with a threshold amount of services (e.g., a threshold number of sessions, a threshold amount of data, etc.) that the device is allowed to consume. The subscriber information may include an indication of the threshold associated with the device. In some cases, the subscriber information may indicate an amount of services (e.g., a number of sessions, an amount of data transmitted to and/or from the device, etc.) that the device has consumed. In particular examples, the subscriber information may include one or more policy counters.

The CHF may store the subscriber information and provide a copy of the subscriber information to the entity performing the process <NUM>. In some examples, the CHF may transmit updated versions of the subscriber information to the entity multiple times, such as at a particular frequency (e.g., every <NUM> hours).

At <NUM>, the entity may store subscriber information in a database. The entity may be implemented by one or more first computing devices, the CHF may be implemented by one or more second computing devices, and the first computing device(s) may be different than the second computing device(s). The entity may store the copy of the subscriber information in a different database than the database in which the CHF stores the other copy of the subscriber information.

At <NUM>, the entity may receive a request from a connected function. In various cases, the connected function may be an SMF and/or a PCF. The entity may receive the request over a communication interface that is different than a communication interface in which the entity receives the subscriber information from the CHF. The request may be for access and/or modification of the subscriber information. For example, the request may indicate an identity of the subscriber (e.g., an IP address of the subscriber), details about a session associated with the subscriber (e.g., a type of services to be transferred in the session, an amount of data that has been already transferred in the session, etc.), a location of the subscriber's device (e.g., in a particular cell region associated with the carrier or outside of the carrier's region), etc..

At <NUM>, the entity determines whether the CHF is reachable. For example, the entity may receive a message from the CHF over the interface connecting the CHF and the entity. In some cases, the entity may attempt to forward the request to the CHF. If the entity does not receive a response from the CHF within a predetermined time period of sending the request, or the entity receives an error message from the CHF, then the entity may conclude that the CHF is unreachable.

If the entity determines that the CHF is reachable at <NUM>, then the process <NUM> proceeds to <NUM>. At <NUM>, the entity may forward the request to the CHF. At <NUM>, the entity may receive a response from the CHF. For example, the response may indicate that the copy of the subscriber information stored by the CHF has been accessed and/or modified in accordance with the request. For instance, the response may include at least a portion of the subscriber information. At <NUM>, the entity may forward the response to the connected function.

If, on the other hand, the entity determines that the CHF is not reachable at <NUM>, then the process <NUM> proceeds to <NUM>. At <NUM>, the entity accesses and/or modifies the copy of the subscriber information stored in the database based on the request. At <NUM>, the entity generates a response based on the accessed and/or modified subscriber information. In some examples, the response includes at least a portion of the copy of the subscriber information stored by the entity. At <NUM>, the entity transmits the response to the connected function.

At <NUM>, the entity may determine that the CHF has become reachable. For example, the CHF may have been temporarily offline or otherwise unreachable by the entity. In various implementations, the entity may determine that the CHF has become reachable by receiving a message from the CHF.

At <NUM>, the entity may transmit updated information to the CHF. In various implementations, the copy of the subscriber information stored by the entity was modified while the CHF was unreachable. For example, a policy counter indicating an amount of data remaining in a plan of the subscriber may have been decreased based on a session that occurred while the CHF was unreachable. In some cases, the copy of the subscriber information was modified at <NUM>. The updated information may indicate one or more changes to the copy of the subscriber information that occurred while the CHF was unreachable. Accordingly, the CHF may reconcile its own copy of the subscriber information based on the activity of the subscriber that occurred while the CHF was unreachable.

<FIG> illustrates an example of at least one device <NUM> configured to perform various methods and functions described herein. The device(s) <NUM> includes any of memory <NUM>, processor(s) <NUM>, removable storage <NUM>, non-removable storage <NUM>, input device(s) <NUM>, output device(s) <NUM>, and transceiver(s) <NUM>.

The memory <NUM> may include component(s) <NUM>. The component(s) <NUM> may include at least one of instruction(s), program(s), database(s), software, operating system(s), etc. In some implementations, the component(s) <NUM> include instructions that are executed by processor(s) <NUM> and/or other components of the device <NUM>. In addition, the memory <NUM> may store instructions for performing operations of the CHF <NUM>, the FOF <NUM>, the connected function <NUM>, or any combination thereof. Although not illustrated in <FIG>, the memory <NUM> may also store a compatible device Operating System (OS), including but not limited to, Microsoft Windows Mobile, Google Android, Apple iOS, Linux Mobile, as well as any other common mobile device OS.

In some embodiments, the processor(s) <NUM> include a central processing unit (CPU), a graphics processing unit (GPU), or both CPU and GPU, or other processing unit or component known in the art. The processor(s) <NUM> may be configured to execute instructions stored in the memory <NUM>.

The device <NUM> may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. Tangible computer-readable media can include volatile and non-volatile, removable and 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. The memory <NUM>, the removable storage <NUM>, and the non-removable storage <NUM> are all examples of computer-readable storage media. Computer-readable storage media include, but are not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, or other memory technology, Compact Disk Read-Only Memory (CD-ROM), Digital Versatile Discs (DVDs), Content-Addressable Memory (CAM), or other optical 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 device <NUM>. Any such tangible computer-readable media can be part of the device <NUM>.

The device <NUM> also can include input device(s) <NUM>, such as a keypad, a cursor control, a touch-sensitive display, voice input device, etc., and output device(s) <NUM> such as a display, speakers, printers, etc. These devices are well known in the art and need not be discussed at length here.

Claim 1:
A method performed by a Fail-Open Function, FOF, (<NUM>), the method comprising:
receiving (<NUM>) at the FOF (<NUM>), from a charging function, CHF (<NUM>), information corresponding to a subscriber of a network, the information including data indicative of use of the network by the subscriber; storing (<NUM>) the information in an offline account database (<NUM>, <NUM>) of the FOF (<NUM>);
receiving (<NUM>) at the FOF, from a connected function, a request (<NUM>) for information about the subscriber associated with a session;
determining (<NUM>) by the FOF that the CHF is unreachable;
based on the request (<NUM>) and on determining that the CHF is unreachable, performing (<NUM>) by the FOF (<NUM>) at least one of accessing or modifying the information stored in the offline account database of the FOF;
based on performing at least one of accessing or modifying the information stored in the offline account database of the FOF, generating (<NUM>) by the FOF a response (<NUM>, <NUM>); and
transmitting (<NUM>, <NUM>) by the FOF the response to the connected function (<NUM>);
determining that the CHF has become reachable; and
based on determining that the CHF has become reachable, transmitting, to the CHF, an indication of the information that has been at least one of accessed or modified.