Outsourcing Authentication, Authorization and Accounting, and Charging and Billing Services to Trusted Third Parties for Future Consumer-Oriented Wireless Communications

Abstract

In this article, proposals for the realization of an infrastructural re-think on the way authentication, authorization and accounting (AAA) services and charging and billing (C&B) services are supplied within the ubiquitous consumer wireless world (UCWW) are set out. Proposals envisage these services being owned and organized by trusted third parties (TTPs) and utilizing new globally standardized protocols and infrastructural entity interfaces. Their implementation will affect a successful realization of the UCWW’s consumer-based techno-business infrastructure, complementing or even replacing the present legacy network-centric, subscriber-based one. The approach enables a loose dynamic, or even casual, consumer-type association between consumers (mobile users) and network/teleservice providers, and it opens the door to multifaceted benefits for consumers, for new network/teleservice providers, and for other new UCWW business entities in addition to the 3P-AAA and 3P-C&B service providers at the heart of this article’s proposals.

1. Introduction

In the ubiquitous consumer wireless world (UCWW) [1,2], the techno-business focus has moved from the legacy network-centric subscriber-based techno-business model (SBM), which continues to be the dominant model in use globally today, to the network-independent consumer-based techno-business model (CBM) [1,2]. This is a paradigmatic change of the architecture and infrastructure, while using the same physical communications technology (e.g., 5G and upcoming 6G), and brings with it many new expectations, such as full mobility of consumers among different wireless access networks and access network providers (ANPs), using a single, fully portable identity, with the attribute of anytime-anywhere-anyhow number portability [1], which, along with other supportive infrastructural changes, will, for the first time, enable the authentic, global, autonomous, user-driven ‘always best connected and best served’ (ABC&S) realization [3]. Creating such freedoms for consumers means that the norm for the payment for wireless communication services will be on a transaction-by-transaction basis. Such consumer-centricity is achieved mainly through a separation of the operation, administration, and management (OAM) of consumers’ authentication, authorization, and accounting (AAA) activity from the supply of wireless network access services and its re-location to trusted third-party AAA service providers (3P-AAA-SPs) [1,2] who are independent of ANPs and become central players in CBM, as illustrated in Figure 1. With the assignment of this crucial role to 3P-AAA-SP entities, the distinction between home ANP and foreign ANP disappears; all, in effect, become ‘local’ ANPs to the mobile user regardless of his/her geographic location. An example, to emphasize the distinction being made here, is that roaming charges will no longer apply; this is an attribute inherent to the new CBM model as the physical ‘home network–foreign network’ basis for roaming charges disappears.

Published ideas nearest to the CBM include the Wireless World Research Forum’s (WWRF) work placing the user at the center of the business model [4]. Also, among the business models considered for cellular operators in Reference [5], the one envisaging the operator acting only as an open bit-pipe provider is close to the CBM idea. Another CBM-like model is the open heterogeneous mobile network architecture from Reference [6], which is realizable on the European Telecommunications Standards Institute’s (ETSI) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN)—Next Generation Networks (NGN) specifications and supported by third-party organizations. ‘Heterogeneous’ there and in this article refers to users gaining wireless access over various disparate access networks, with handovers between such networks being possible. Within the mobile commerce services domain, the Global System for Mobile Communications Association’s (GSMA) ‘mobile-money’ and ‘pay-buy-mobile’ [7] initiatives manifest functionality and security attributes akin to certain requirements in CBM. While these schemes are clearly subscriber-based, the role of the new ‘trusted services manager’ entity echoes aspects of the functional role of 3P-AAA-SPs in CBM.

With reference to the classic consumer wireless business and service model diagram, Figure 1, it is through the business agreements (solid arrowed lines) that the various service-offering entities—ANPs, teleservice providers (TSPs) and value-added service providers (VASPs)—have with the 3P-AAA-SPs that those entities receive payments for the (value-added) teleservices (dashed arrowed lines) used by consumers. The term ‘business agreement’ here is loosely defined, as the payment scheme can be singularly granular, e.g., implemented through a standardized secure protocol infrastructure on a transaction-by-transaction basis.

Along with the required AAA restructuring in UCWW, all of the charging and billing (C&B) functions need to be re-visited, re-structured, and re-distributed in a coherent, logical, and reasonable way as well. The form of the novel third-party C&B (3P-C&B) service architecture solution proposed here is one that, in part, can work under the 3P-AAA-SP administration. It is a possible rather than definitive solution, catering to many of the new C&B requirements arising in UCWW.

The rest of this article addresses the 3P-AAA and 3P-C&B issues in UCWW, proposing potential architectural and protocol solutions for their realization.

Table A1. Main abbreviations used in the article.

Abbreviation	Full Name
AAA	Authentication, Authorization and Accounting
ABC&S	Always Best Connected and best Served
AccRec	Accounting Record
ADA	Advertisement, Discovery and Association
ANP	Access Network Provider
ASI	Application-Specific Information
ASM	Application-Specific Module
AVP	Attribute Value Pair
CBM	Consumer-Based techno-business Model
C&B	Charging and Billing
CC	Credit Control
CCA	Credit Control Answer
CCR	Credit Control Request
CDR	Charging Detail Record
CIM	Consumer Identity Module
HAC	Hot Access network Change
IHN	Integrated Heterogeneous Networking
QoS	Quality of Service
SBM	Subscriber-Based techno-business Model
SE	Service Equipment
SLA	Service Level Agreement
STA	Session Termination Answer
STR	Session Termination Request
TSP	Teleservice Provider
TTP	Trusted Third Party
UCWW	Ubiquitous Consumer Wireless World
VASP	Value-Added Service Provider
WBC	Wireless Billboard Channel
3P-AAA	Third-Party AAA
3P-AAA-SP	Third-Party AAA Service Provider
3P-C&B	Third-Party Charging and Billing

in Appendix A contains the main abbreviations used in the article.

2. Third-Party Authentication, Authorization and Accounting (3P-AAA)

The creation of trusted 3P-AAA service processes, largely through global standards, and corresponding 3P-AAA-SP entities is vital for enabling the CBM-based UCWW environment. This will establish a new, trusted, and secure infrastructure which can be used for accounting (followed by respective payment) of the usage of all network access services and teleservices. In many of its features, the 3P-AAA service is envisaged as a wireless equivalent of the credit-card type service. While an autonomous 3P-AAA service is viewed as key and essential to realizing the UCWW, different solutions may be conceived for the 3P-C&B service, from its remaining within the domain of the service provider to being co-located with the 3P-AAA entity. In Section 3, a solution in which the 3P-C&B service is integrated with the 3P-AAA service is described and examined.

2.1. 3P-AAA Framework Architecture

A scalable, hierarchical, and cognizant 3P-AAA architecture was elaborated upon in Reference [8] by closely following the next generation networks (NGN) guidelines outlined by the IMS/NGN Forum, as it strives for the centralization of consumer and product data, service personalization, multi-dimensional charging, and policy management. As 3P-AAA-SPs may offer services on a global scale, a hierarchical architecture—with servers on the international, national, regional, and local levels as the customer base dictates—is preferable for both scalability and latency reasons to a flat structure with long AAA proxy/relay chains. This would supersede the present-day (SBM) flat structure for intra-network and ‘network↔network’ AAA signaling [1]. The local-level servers of a particular 3P-AAA-SP will receive AAA requests from 3P-AAA clients installed on consumer mobile devices or from local AAA servers of ANPs/TSPs/VASPs for specific communication/service sessions initiated by consumers, in the first instance. If the server does not recognize the consumer/ANP/TSP/VASP, it will seek information from the next level on the hierarchy, and so on, eventually receiving back information to enable or reject (e.g., the latter in the case of insufficient credit for a particular consumer) the AAA procedure for the requesting consumer/ANP/TSP/VASP. While all charging, billing, debit, credit, and AAA information for a consumer/ANP/TSP/VASP may be stored in either a centralized or distributed way by 3P-AAA-SPs, the 3P-AAA servers at the top hierarchical layer will have an entry for every one of their 3P-AAA customers through which a full AAA service may be initiated. Accounting information in relation to communication/service sessions initiated by consumers (and confirmed by them) is collected from the corresponding local AAA servers of respective ANPs/TSPs/VASPs by the local-level 3P-AAA servers of 3P-AAA-SPs and forwarded upwards through the hierarchy. The creation of a type of cognizant 3P-AAA service to support more efficient, low-latency service provision is possible, via reflecting updated AAA information at a higher hierarchy level to the local-level 3P-AAA servers where specific consumers’/ANPs’/TSPs’/VASPs’ AAA requests are expected.

2.2. 3P-AAA Functional Model

A schematic of the key features of the elaborated 3P-AAA functional model, a modified version of that found in Reference [9], is presented in Figure 2. In this, four new interfaces are defined, and their reference points are identified in the model. It is over these that the new 3P-AAA signaling elaborated on below will occur. The international standardization of these interfaces and of this signaling (or variants of this) is a requirement for the global realization of UCWW.

In addition to the third-party aspect of the AAA provision, another novel element here (Figure 2) is the installation of an AAA client directly on the mobile device. This marks a radical distinction from the traditional Diameter/COPS models. Operationally speaking, a smart consumer identity module (CIM) card (e.g., based on the ‘Java card’ technology [10]), inserted into the mobile device, could carry the 3P-AAA client application for AAA communication with various service providers.

The key role in the 3P-AAA functional model is played by the 3P-AAA interfaces, since they enable communication between different entities. Due to the resilience requirements and sensitivity of the data traversing these interfaces, a careful examination of the functionality of each interface has been performed. The key elements of this are elaborated on below. The challenge is that the creation of 3P-AAA would give rise to new forms of interactions and scenarios that have not been previously seen. For example, regarding the decoupling of the provision of teleservices from that of network access communication services, the interactions with third-party VASPs should be direct through one of these interfaces. This is quite different from the way third-party VASP services have been accessed traditionally, i.e., through home access networks (‘home ANs’) where a service level agreement (SLA) exists between the home ANP and a third-party VASP [8]. Thus, prior to the actual service deployment, the VASP has to be plugged into the IMS open service access (OSA) or another service delivery platform (SDP). The principal role of these entities is that they perform accounting and charging tasks and provide information with respect to the network resources that can be accessed by the third-party VASP. Within 3P-AAA functional model described here, these entities can be replaced by the 3P-AAA-SPs entities with respective interface interactions for the provision of AAA and C&B services. As indicated elsewhere, access to network resources can be advertised through other entities of UCWW, e.g., wireless broadband channels (WBCs) and advertisement, discovery and association (ADA) agents [11].

Ideas on a multi-class 3P-AAA architectural model have been published, e.g., in Reference [2], where three classes corresponding to major foreseeable market sectors for the 3P-AAA business are proposed. These are ‘Class A’ 3P-AAA-SPs serving the ANPs, ‘Class B’ 3P-AAA-SPs serving the TSPs and VASPs, and ‘Class C’ 3P-AAA-SPs serving the consumers. This enterprise market model is followed here, and it is shown in Figure 2. The approach to segregating the 3P-AAA-SP market also holds promise for a more orderly global standardization process.

2.2.1. 3P-AAA Interfaces

The 3P-AAA functional model is based on the following four application–layer interfaces (c.f., Figure 2), all new to the wireless communications world:

(a)

3P-AAA interface a (consumer ↔ ANP/TSP/VASP)

This interface carries signaling information between a 3P-AAA client, installed on a consumer mobile device, and the local AAA server of an ANP/TSP/VASP whose services are used by this consumer. It is over this interface that a 3P-AAA session, associated with the forthcoming service usage by the consumer, is established and maintained. The aliveness of this session is monitored by the exchange of signaling messages. In case of events that might cause a change in the 3P-AAA session state, an informative update message is exchanged between the communicating parties. When the consumer has finished using the service, a 3P-AAA session termination procedure would take place.

(b)

3P-AAA interface b (consumer ↔ 3P-AAA-SP)

This interface carries signaling information between a 3P-AAA client, installed on a consumer mobile device, and a corresponding ‘Class C’ 3P-AAA server of a 3P-AAA-SP who serves this consumer. It should be noted that the consumer may have an arrangement with more than one ‘Class C’ 3P-AAA-SP, with various policies for the selection of the 3P-AAA-SP for any specific teleservice.

A number of diverse tasks are attributed to this b interface. By making use of it, the consumer would be able to interact with his/her 3P-AAA account for purposes like checking the account balance, topping up the account, and adjusting possible profile settings.

(c)

(3P-AAA interface c (ANP/TSP/VASP ↔ 3P-AAA-SP)

This interface carries signaling information between the local AAA server of an ANP/TSP/VASP and a corresponding 3P-AAA server of a ‘Class A/B’ 3P-AAA-SP who serves this ANP/TSP/VASP. Each ANP/TSP/VASP creates its own accounting (and credit-control) streams, corresponding to the usage of its services by consumers, which are forwarded to the corresponding ‘Class A/B’ 3P-AAA-SP. Consumers may use more than one (value-added) teleservice in parallel, of course, represented as a multiplication of the single (value-added) teleservice usage case, and, in addition, may avail simultaneously of the network access services of multiple ANPs. In such cases, each involved ANP/TSP/VASP generates separate accounting (and credit-control) streams related to each individual service usage, respectively. As accounting (and credit-control) messages related to the service session are exchanged over this interface, its resilience is of paramount importance. Thus, it should be able to handle failover scenarios. In some scenarios during which connection to the 3P-AAA server might be lost during an on-going session, it would be appropriate for the network/service provider to store accounting data locally without service interruption and later forward updated data to the 3P-AAA-SP. This interface also supports flexible charging through the adoption of online and offline charging capabilities, as described in detail in the next section. Online charging is analogous to the idea of prepaid services, where, in order to access services, a credit check is first performed on the consumer account and a certain amount is debited or reserved. However, online charging is performed in real-time and can thus influence the session state. Offline charging is less stringent and does not require credit-control facilities. When offline charging is used, the service usage is reported, and charges are applied based on the consumed amount. Generally, this type of charging is less flexible and is typically used for the postpaid services.

(d)

3P-AAA interface d (3P-AAA-SP_A/B/C↔3P-AAA-SP_B/C/A)

This interface carries signaling information between 3P-AAA servers belonging to different classes of 3P-AAA-SPs. When using the services of multiple ANPs/TSPs/VASPs, the consumer must be ensured that the charges applied by these diverse entities are indeed accurate. Thus, after each service session termination, each involved ‘Class A/B’ 3P-AAA-SP will furnish the relevant charging detail record (CDR) for the recently terminated session to the corresponding ‘Class C’ 3P-AAA-SP, so the latter can aggregate the appropriate CDR information and check whether the charges applied have been accurate or not. This is followed by a corresponding request to debit or credit the consumer’s account. As the corresponding messages, along with other accounting and credit-control messages related to the service session, are exchanged over this interface, it must handle various failover scenarios for improved resilience.

Application autonomy (i.e., containing all of the required 3P-AAA functionality with defined messages for third-party authentication, authorization and accounting, purchase transactions, consumer privacy, mobility, etc.) would help with the development of standards across these 3P-AAA interfaces. A possible approach to this is proposed in Reference [12] by implementing a new 3P-AAA signaling application sitting on top of the IETF’s Diameter base protocol [13]. However, as this protocol defines only a general framework for AAA implementation and does not contain command codes for authentication and authorization (which are usually application-specific), new command codes and attribute value pairs (AVPs) need to be defined [12].

2.2.2. 3P-AAA Messages

An initial list of the main signaling messages for use over the newly defined 3P-AAA interfaces was elaborated and described in Reference [14] for 3P-AAA interfaces a, b, and c and in Reference [15] for 3P-AAA interface d. An updated and refined version of this list is shown in

Table 1. The main signaling protocol messages over the four new 3P-AAA interfaces.

Message	3P-AAA Interface a	3P-AAA Interface b	3P-AAA Interface c	3P-AAA Interface d
3P-AAA-Start-Request/Answer	√		√	√
3P-AAA-Update-Request/Answer	√		√	√
3P-AAA-Service-Cost-Enquiry- Request/Answer	√			√
3P-AAA-Account-Balance-Check- Request/Answer		√	√	√
3P-AAA-Account-Top-Up- Request/Answer	√	√
3P-AAA-Termination-Request/ Answer	√		√	√
3P-AAA-Account-Debit-Request/ Answer				√
3P-AAA-Account-Credit-Request/ Answer				√
3P-AAA-Furnish-CDR-Request/ Answer				√

.

2.2.3. 3P-AAA Protocol Stack

In Reference [12], it was proposed that the new 3P-AAA signaling application utilize a 3P-AAA protocol stack built on the generic AAA server architecture defined in Reference [16]. The good reason given is that utilizing such a layered structure is effective for grouping service-specific functions together and for providing architecture flexibility (e.g., to replace any layer’s functionality with an equivalent functionality without disrupting the adjacent layers).

2.2.4. 3P-AAA Policy-Based Accounting

A policy-based accounting mechanism [17] is utilized by 3P-AAA in order to communicate accounting policies (to ANP/TSP/VASP domains), which are subject to business agreements among the various actors. Basically, accounting policies describe the rules for the generation, transport, and storage of accounting data. Each rule consists of two parts [17]: (i) a condition part with attributes (variables in a policy condition statement), expressing under which condition the policy should be enforced; and (ii) an action part, defining the action (e.g., parameter configuration of the accounting infrastructure) which takes place if the condition is true.

A discrete (in contrast to an integrated) policy-based accounting approach is utilized by 3P-AAA, as it is more flexible and more generic. In addition, this allows for outsourcing the accounting task to a general accounting system, which can account for different services thanks to the decoupling of accounting from the actual services being provided. As mentioned in Reference [17], this option may speed up the creation of new services, especially specialized content services provided via the Internet. This, however, was not elaborated on further in Reference [17] but does come closer to the 3P-AAA idea which was conceived independently in Reference [18] and elaborated on in great detail later, e.g., in References [1,2]. It should be noted that third-party charging and billing (3P-C&B) is not considered as an option in Reference [17].

With respect to the ANP/TSP/VASP domain, the accounting policies [17] can be either local policies residing on the local AAA server (i.e., for intra-domain accounting), or external policies (i.e., for inter-domain accounting) obtained from the 3P-AAA-SP (or consumer) domain either by pulling (when needed) from the 3P-AAA-SP (or consumer) domain to the ANP/TSP/VASP domain or by pushing, depending on the utilized authorization model as described in Section 2.3.

The external accounting policies obtained serve as 3P-AAA-SP’s (or consumer’s) instructions for the corresponding ANP/TSP/VASP regarding the desired accounting record type and report frequency so that it can set up and configure the accounting process in accordance with these policies. After obtaining (one way or another) an external accounting policy, the local AAA server in the ANP/TSP/VASP domain evaluates and combines it with the local accounting policy and enforces the result on the corresponding service equipment (SE) for the provision of the actual service (i.e., a network access service provided by an ANP, or a [value-added] teleservice provided by a VASP/TSP). SE, for example, could be an access router/network access server (NAS) or a quality of service (QoS) router (supported by a local bandwidth broker) [19] operating in the domain of the consumer-chosen ANP, or a messaging/content/application server [20] operating in the domain of the (usually) consumer-chosen TSP/VASP.

2.3. Authorization Models

Regarding the identification of a suitable authorization model for the 3P-AAA provision, the possible options, defined in Reference [19], include the agent, pull, and push sequence models. The use of these models for the 3P-AAA service provision has been initially discussed in Reference [21]. A more advanced and refined version of the utilization of these models for 3P-AAA is shown in Figure 3 and described in the next subsections.

2.3.1. Agent Model

In the agent authorization model, the local AAA server of the corresponding ANP/TSP/VASP operates as an agent between the consumer’s mobile device and SE.

Table 2. Main signaling messages of the agent authorization model.

No.	Name	Description
1	Authentication and authorization request	This message is sent by the consumer’s mobile device (on behalf of the consumer who needs a particular service) to the local AAA server of the corresponding ANP/TSP/VASP (providing that service).
2	Authentication and authorization request	This message is forwarded by the local AAA server to the corresponding 3P-AAA-SP’s server for the authentication and authorization of the consumer.
3	Authentication and authorization reply	This is the reply of the 3P-AAA-SP’s server sent back to the local AAA server. The 3P-AAA-SP’s server first applies policy fitting to the authentication and authorization request in order to make a decision (i.e., approving or denying it). If an approval is granted, then this is communicated back to the local AAA server along with the corresponding extra-domain 3P-AAA accounting policy (stored on the 3P-AAA-SP side) piggybacked onto this message.
4	Service setup request	This message is sent by the local AAA server to the relevant SE asking it to set up the requested service. The local AAA server first evaluates the retrieved extra-domain 3P-AAA accounting policy, then combines it with the local accounting policy and enforces the result on the corresponding SE (in addition to sending accounting configuration information). For instance, a NAS may enforce destination IP address limits via filters, or a QoS router may enforce QoS restrictions on passing IP packets, as per Reference [19].
5	Service setup reply	After setting up the requested service, SE acknowledging this to the local AAA server.
6	Authentication and authorization reply	This is the reply of the local AAA server sent back to the consumer’s mobile device, telling it that the authentication and authorization process has been completed and that the service has been set up with the specified parameters. An indication of the SE location could also be sent along with this message.
7	Service request	With this message, if the consumer’s mobile device accepts the service setup with the specified parameters, it requests the provision of the service from the respective SE.
8	Service reply	This is the reply of SE sent back to the consumer’s mobile device to confirm the service provision. After that, the SE immediately starts providing the requested service.
9	Accounting indication	These are interim accounting indication messages that are sent regularly by the SE (through the local AAA server towards the 3P-AAA-SP’s server), as per Reference [22], e.g., due to using a tariff with variable price, i.e., higher price during peak hours compared to off-peak hours, or change in the tariff during an ongoing service session as a result of ANP-driven roaming (usually consumer-transparent in operation, but perhaps not so in cost/accounting), or re-authorization of a service session with improved QoS. The latter could happen, for instance, along with a consumer-driven hot access network change (HAC). The HAC is analogous to the vertical handover concept in the existing SBM-based wireless access networks, but its structure, as a consumer-driven integrated heterogeneous network (IHN), the reasons for it, and its consequences are quite different, so a different term is coined for the CBM model. A typical ABC&S reason for HAC would be the availability of a better access option and offer from another access network for an ongoing teleservice. The HAC execution, which could be automated on the back of a consumer QoS policy, results in the production of accounting records for each part, i.e., in relation to the network access service consumed before and after the HAC execution, usually from two different ANPs, i.e., when an HAC occurs, the first ANP service transaction is closed just as though the service terminated, and the second one is independently commenced with the ANP, and all this while the service perception for both the consumer and the TSP/VASP is of a single teleservice and transaction. Additional summarization of the interim accounting data and the elimination of duplicate data [22] may be performed by the local AAA server before forwarding the data to the 3P-AAA-SP’s server. At the end of the service session, a similar end-of-session accounting indication message is delivered to the 3P-AAA-SP’s server, which translates all accounting data received into a session record.

contains the main signaling messages exchanged (and possibly acknowledged, where needed) between corresponding entities if this model is followed.

The agent model allows the original consumer’s authentication and authorization request (message 1 in Table 2) to also contain an accounting policy indication (e.g., the desired parameters for the provisioning of the accounting service such as the report interval or the accounting record format), which could be communicated (using message 2 in Table 2) by the local AAA server to the 3P-AAA-SP’s server and regarded by the latter [21].

2.3.2. Pull Model

The pull authorization model is the most efficient one among the three models as it results in the lowest number of message exchanges between the communicating parties. In addition, it is the least intrusive from the viewpoint of the local AAA server of the ANP/TSP/VASP. Thus, it is considered as the primary model for the 3P-AAA service implementation in UCWW.

Table 3. Main signaling messages of the pull authorization model.

No.	Name	Description
1	Service request	This message is sent by the consumer’s mobile device on behalf of the consumer to request a particular service directly from the respective SE providing it. This message may also contain a consumer’s accounting policy indication.
2	Authentication and authorization request	This message is sent by the SE to the local AAA server of the ANP/TSP/VASP with a request to authenticate the consumer and authorize him/her to use the requested service.
3	Authentication and authorization request	This message is forwarded by the local AAA server to the 3P-AAA-SP’s server for authentication and authorization of the consumer.
4	Authentication and authorization reply	This is the reply of the 3P-AAA-SP’s server sent back to the local AAA server. The 3P-AAA-SP’s server first applies policy fitting to the authentication and authorization request in order to make a decision (i.e., approving or denying it). If an approval is granted, then this is communicated back to the local AAA server along with the corresponding extra-domain 3P-AAA accounting policy (stored on the 3P-AAA-SP side) piggybacked onto this message.
5	Authentication and authorization reply & Service setup request	This message is sent back by the local AAA server to the SE. The local AAA server first evaluates the retrieved extra-domain 3P-AAA accounting policy, then combines it with the local accounting policy and enforces the result on the corresponding SE (in addition to sending accounting configuration details).
6	Service reply	This is the SE’s reply sent back to the consumer’s mobile device telling it that the authentication and authorization process has been completed and that the requested service has been set up with the specified parameters. After that, the SE immediately starts providing the service.
7	Accounting indication	During (and at the end of) the service session, such interim (and end-of-session) accounting indication messages are sent by the SE through the local AAA server to the 3P-AAA-SP’s server.

contains the main signaling messages exchanged (and possibly acknowledged, where needed) between the corresponding entities if this model is followed.

2.3.3. Push Model

In the push authorization model, communication (for the purposes of authentication and authorization) between the AAA servers and the SE is relayed through the consumer’s mobile device rather than directly between themselves, which is the main drawback of this model.

Table 4. Main signaling messages of the push authorization model.

No.	Name	Description
1	Ticket request	This message is used by the consumer’s mobile device (before requesting the actual ANP’s/TSP’s/VASP’s service) to ask the corresponding 3P-AAA-SP’s server for a ticket (with some time limit imposed upon it) to be used subsequently with the chosen ANP/TSP/VASP.
2	Ticket reply	This message contains the ticket, issued by the 3P-AAA-SP’s server, verifying that the consumer has an up-to-date account with the corresponding 3P-AAA-SP. The ticket is digitally signed using the 3P-AAA-SP’s private key.
3	Authentication and authorization request	This message is sent by the consumer’s mobile device (on behalf of the consumer who needs a particular service) to the local AAA server of the corresponding ANP/TSP/VASP (providing that service). The message contains the obtained 3P-AAA-SP’s ticket (along with the consumer‘s accounting policy indication, if any) for checking (using the 3P-AAA-SP’s public key) and validation (based on the established trust relationship between the ANP/TSP/VASP and the 3P-AAA-SP) by the local AAA server.
4	Accounting policy request	This message is forwarded by the local AAA server to the corresponding 3P-AAA-SP’s server in order to request the extra-domain 3P-AAA accounting policy.
5	Accounting policy reply	This is the reply of the 3P-AAA-SP’s server to the local AAA server, containing the requested extra-domain 3P-AAA accounting policy.
6	Service setup request	This message is sent by the local AAA server to the relevant SE, asking it to set up the requested service. The local AAA server first evaluates the retrieved extra-domain 3P-AAA accounting policy, then combines it with the local accounting policy and enforces the result on the SE (along with also sending accounting configuration information).
7	Service setup reply	After setting up the requested service, SE acknowledges this to the local AAA server.
8	Authentication and authorization reply	This is the reply of the local AAA server sent back to the consumer’s mobile device, telling it that the authentication and authorization process has been completed and that the service has been set up with specified parameters. This message contains another ticket, which is digitally signed by the local AAA server using the private key of the corresponding ANP/TSP/VASP. An indication of the SE location could also be sent along with this message.
9	Service request	With this message, if the consumer’s mobile device accepts the service setup with the specified parameters, it requests the provision of the service from the respective SE, by also including the ticket issued by the corresponding ANP/TSP/VASP. SE uses the ticket to verify that the request was approved by the local AAA server.
10	Service reply	This is the reply of the SE sent back to the consumer’s mobile device to confirm the service provision. After that, the SE immediately starts providing the requested service.
11	Accounting indication	During (and at the end of) the service session, such interim (and end-of-session) accounting indication messages are sent by the SE through the local AAA server and towards the 3P-AAA-SP’s server.

contains the main signaling messages exchanged (and possibly acknowledged where needed) between the corresponding entities if this model is followed.

The push model allows for end-to-end (direct) authentication and authorization [19], which is an advantage over the other two models. In addition, it seems useful for a ‘voucher style’ selling of the 3P-AAA service [23]. However, in comparison to the agent and pull models, this model places significantly more AAA-related set-up signaling onus on the consumer’s mobile device (in terms of the number of exchanged messages). However, it has the attraction that fuller control rests with the consumer.

A combined utilization of these models is envisaged in Reference [19] for the so-called ‘distributed service’, offered by several service providers acting in cooperation (but not for the 3P-AAA case or context, even though the SuperOrg idea [19] of a wholesaler or broker entity providing authentication and authorization, but without accounting, to organizations delivering services to users, is heading in the direction of 3P-AAA). In this case, the initial user’s request for such distributed service is authenticated and authorized by the first service provider, then it is forwarded to the second service provider, and so on in a chain. The model utilized between the user and the first service provider may be different from that between the first and second service providers, and so on [19].

2.4. Using Pull Authorization Model for 3P-AAA

Figure 4 depicts the case of both an ANP and a TSP using the pull model for the provision of a single network access service and a single teleservice to a consumer without HAC (i.e., the ANP is not changed during the teleservice session), taking into account the possible existence of different classes of 3P-AAA-SPs. The charges for the usage of the teleservice (or the network access service) are based upon the accounting record stream (19) generated by the respective SE of the TSP, or (17) for the ANP, which is forwarded (through the local AAA server) to the corresponding 3P-AAA server of ‘Class B’ (or ‘Class A’) 3P-AAA-SP to which the TSP (or the ANP) is registered. The 3P-AAA server of ‘Class B’ (or ‘Class A’) 3P-AAA-SP forwards (20), or (18), this accounting stream to the 3P-AAA server of ‘Class C’ 3P-AAA-SP, to deduct the appropriate monetary units from the consumer’s account. With regard to the consumer’s authentication and authorization, additional messages are required, namely the requests (4) and (12) forwarded by the 3P-AAA servers of the ‘Class A’ 3P-AAA-SP and ‘Class B’ 3P-AAA-SP to the 3P-AAA server of the ‘Class C’ 3P-AAA-SP, and the corresponding replies (5) and (13).

It may be noted that a similar interaction (i.e., message sequence) occurs if a consumer uses the (independent) teleservices of two teleservice providers simultaneously. This may be illustrated by the addition of another TSP signaling column. Such an approach could also be imagined for the purposes of imagining the schematic interplay of two (or more) ANPs where consumer-driven or TSP-driven HAC occurs.

Figure 5 depicts in more detail the use of the pull model for the 3P-AAA provision (for simplicity, the different classes of 3P-AAA-SPs are not shown), as per Reference [21], based on the NeTraMet metering example described in Reference [17]. Additional entities, such as application-specific modules (ASMs), meters, meter readers, and meter managers, are included in this figure in order to illustrate how accounting policies can be used to configure different meters, as per [17]. In this example, the extra-domain 3P-AAA accounting policy is obtained by pulling it from the 3P-AAA server by the local AAA server (located in the ANP/TSP/VASP domain), which then evaluates it (e.g., by considering the report interval or accounting record format requested by the 3P-AAA server) and then combines it with the local policy. After that, the local AAA server sends corresponding application-specific information (ASI) about the meter configuration to the ASM, which converts it into appropriate configuration information (e.g., the relevant flows, attributes, and reader instructions), which is passed to the meter manager that configures the meter and meter reader in accordance with the given configuration (e.g., configuring the meter how exactly to measure the requested attributes and instructing the meter reader as to the frequency of providing the accounting records) [17].

As was pointed out in Reference [17], in order to avoid duplicated functionality, it should be possible to (re)use the accounting resources already deployed by providers in their domains. Thus, the configuration of different types of accounting modules (e.g., meters) should be possible. Meters are needed in the ANP/TSP/VASP domain to capture data about service consumption. A configurable meter captures meter data only for flows specified by the metering policy. In addition to the metering scope, the metered flow granularity and attributes (i.e., which data are to be collected for a specific flow), and the meter accuracy (i.e., the measurement intervals) are specified for each service usage. The captured data about the service consumption are collected by a meter reader, which sends the metering records to ASM. In turn, ASM uses these to fill in the required accounting records, which are then sent through the local AAA server to the 3P-AAA server. For the generation of actual accounting records, additional data conversion, aggregation, and filtering might be performed at different stages, as envisaged in Reference [17]. The ANP/TSP/VASP can either post-process the accounting data or directly forward them to the 3P-AAA-SP, which uses these data as an input to generate an invoice (by using relevant C&B policies, e.g., tariff formulas) for the corresponding service usage, which is sent to the consumer at the end. As an additional option, accounting records can also be offered as a special service to the consumer, e.g., in the form of an accounting indication of how much resources have been used up to the time of the indication so as to obtain an orientation about the current cost incurred for using the service and avoid exceeding the spending limits set by the consumer. In addition, such accounting indications may give the consumer a hint as to which particular service component usage has caused the (over-)charges, so an instant decision could be taken by him/her to stop using it immediately. For this, however, a separate authorization is required [17].

Figure 6 shows the use of the main messages, listed in Table 1, for the 3P-AAA signaling (without HAC) described below.

The consumer’s mobile device has a 3P-AAA client application installed on it. As per the directions given in Reference [13], the SE operates as a ‘Diameter 3P-AAA client’, the local AAA server and the ‘Class A/B’ 3P-AAA server each operate as a ‘Diameter 3P-AAA proxy’, and the ‘Class C’ 3P-AAA server operates as a ‘Diameter 3P-AAA server’. All of these Diameter nodes support the Diameter base protocol (including the accounting functionality) and the newly proposed 3P-AAA Diameter application. The use of other types of supplementary Diameter nodes, such as relay, redirect, and translation agents, is also possible; the operation of such nodes for the 3P-AAA provision is similar to that described in Reference [13].

Initially, according to the pull authorization model, the consumer’s mobile device requests access to a service from the corresponding SE providing that service (i.e., a network access service, a teleservice, or a value-added teleservice). This message could be an extended version of the first message used by the respective protocol associated with the chosen service. For instance, if the consumer wants to make a ‘voice over Internet protocol (VoIP)’ call to another consumer by utilizing the session initiation protocol (SIP), then an extended version of the SIP Register message could be used, as per Reference [20]; the SE in this case will act as an SIP proxy/registrar. After the SE acknowledges the receipt of the consumer’s service request, then the following procedures are executed, as illustrated in Figure 6:

(1)

3P-AAA start-up procedure:

• The consumer’s mobile device sends a 3P-AAA-Start-Request message to the SE, which triggers the establishment of a session between the SE and the 3P-AAA server of the corresponding ‘Class C’ 3P-AAA-SP serving this consumer. As a 3P-AAA-service-specific message, supported by the newly proposed 3P-AAA Diameter application, the 3P-AAA-Start-Request message contains a Session Id AVP, as per directions given in Reference [13]. The Session Id AVP is also used in all subsequent messages, e.g., for authorization, accounting, etc., relating to this session, as a means for all involved parties to correlate a particular exchanged message with this session).
• SE forwards the received 3P-AAA-Start-Request message to the ‘Class C’ 3P-AAA server via the local AAA server of the corresponding network/service provider and the 3P-AAA server of the corresponding ‘Class A/B’ 3P-AAA-SP serving this provider. Both servers identify that this request cannot be locally processed (based on information found in the message, e.g., the value of the Destination–Realm AVP) and thus forward it to the next hop.
• The ‘Class C’ 3P-AAA server checks the consumer’s profile, performs general consumer authorization, e.g., to apply a certain payment discount at the end of the service session because the consumer reached a certain credit threshold (the extra service cost in this case is covered by the corresponding ‘Class C’ 3P-AAA-SP), and confirms its readiness to start a third-party accounting for the upcoming service session by returning a 3P-AAA-Start-Answer message. The identified type (prepaid or post-paid) of consumer is also included in this message, e.g., as part of the Consumer-3P-AAA-Data AVP; this information is intended for the SE as means to figure out whether credit control must be subsequently performed. (In the case of a prepaid consumer, the local AAA server or ‘Class A/B’ 3P-AAA server may additionally send a 3P-AAA-Account-Balance-Check-Request message to the ‘Class C’ 3P-AAA server, asking the latter to confirm whether the minimum amount of funds is available [or not] in the consumer’s account.)
• The ‘Class A/B’ 3P-AAA server performs its own service-specific authorization (i.e., the service usage is allowed based on the consumer’s subscription to a service or a group of services, leading to a possible payment discount), and acknowledges its readiness to start a third-party accounting for the upcoming service session by returning a 3P-AAA-Start-Answer message to the local AAA server.
• Acting as a ‘Diameter 3P-AAA proxy’, the local AAA server is responsible for making ‘local accounting policy’ decisions related to service usage and provisioning, and corresponding maintenance of the SE in order to enforce the proper service usage and provide adequate admission control and provisioning. The local AAA server understands the semantics of all messages passing through it and can modify some of these so as to implement policy enforcement or reject others when a local policy is violated [13]. After receiving the 3P-AAA-Start-Answer message from the ‘Class A/B’ 3P-AAA server, the local AAA server performs its own service-specific authorization (i.e., the service usage could be allowed based on a certain QoS level as requested by the consumer or downgraded to another QoS level due to lack of sufficient network/service resources at the moment or lack of sufficient funds in the consumer’s account being signaled by the ‘Class C’ 3P-AAA server), and acknowledges its readiness to start the accounting process for the upcoming service session by returning a 3P-AAA-Start-Answer message to the corresponding SE.
• The SE prepares the service delivery accordingly (as per the QoS level authorized by the local AAA server for the subsequent service provision) and acknowledges this back to the consumer’s mobile device by sending a 3P-AAA-Start-Answer message. This way the 3P-AAA start-up procedure is completed.

(2)

Accounting procedure:

• The SE grants access to the consumer’s device to use the service and starts collecting accounting information for this new service session.
• Using the instructions of the ‘Class C’ 3P-AAA server defining the method of forwarding the accounting data (based on the server’s knowledge of the consumer) along with the accounting record timeliness requirements, the SE (periodically) sends the collected accounting records to the server, which provide a snapshot of the current service usage. The periodically sent interim account records are useful in the case of a device reboot or other network problems preventing the delivery of a session record at the end of the service session. The standard Accounting-Request (ACR) messages of the Diameter base protocol are used to send the accounting records to the ‘Class C’ 3P-AAA server, which replies with an Accounting-Answer (ACA) message for each of these to acknowledge or not its reception.
• After obtaining the accounting record(s), a 3P-AAA server may perform additional tasks, such as checking, ordering, correlation, fraud detection, etc. (either immediately after reception of the record or in a post-processing manner), by inspecting the relevant AVPs, as recommended in Reference [13]. In order to limit the financial risk, real-time accounting with time constraints could also be used, as defined in Reference [20], imposing the processing of information on service usage within a finite time window by using the Accounting-Realtime-Required AVP to control the SE behavior when the transfer of accounting records is delayed or unsuccessful.
• A final accounting record (STOP_RECORD), sent in the same fashion, completes the accounting procedure at the end of the service session.

(3)

3P-AAA end procedure:

• The ending of the service session can be initiated either by an AAA server or the SE (e.g., due to lack of remaining credit in the consumer’s account or expiration of the authorized service time, specified in the Session-Timeout AVP), or by the mobile device as per the consumer’s desire/action.

  ○

  In the former case, the entity wishing to end the session sends a 3P-AAA-Termination-Request message backward to the consumer’s mobile device (via the other intermediate entities involved), which replies with a 3P-AAA-Termination-Answer message.

  ○

  In the latter case, the 3P-AAA-Termination-Request message is sent by the consumer’s mobile device to the SE, which replies with a 3P-AAA-Termination-Answer message.

• Subsequently, the SE sends a Diameter base protocol Session-Termination-Request (STR) message to the ‘Class C’ 3P-AAA server (via the local AAA server and ‘Class A/B’ 3P-AAA server) so as to free up resources associated with the provision of the terminated session, and the ‘Class C’ 3P-AAA server replies with a Session-Termination-Answer (STA) message.
• Afterward, the 3P-AAA end procedure continues with relevant balance settings between the ‘Class C’ 3P-AAA server and the ‘Class A/B’ 3P-AAA server with respect to crediting (or debiting) the consumer’s account with any funds which were incorrectly/inappropriately (not) taken by the ‘Class A/B’ 3P-AAA-SP, through the exchange of 3P-AAA-Account-Credit-Request/Answer (or 3P-AAA-Account-Debit-Request/Answer) messages.

During the service session, the consumer may send to the network/service provider an enquiry about the cost of its service and receive an answer (by means of 3P-AAA-Service-Cost-Enquiry-Request/Answer messages) or may request an account balance check from his/her ‘Class C’ 3P-AAA-SP and receive an answer (by means of 3P-AAA-Account-Balance-Check-Request/Answer messages). This latter could also be initiated by a local AAA server or by a ‘Class A/B’ 3P-AAA server.

In addition, during an ongoing service session, a 3P-AAA update procedure could be initiated (by means of 3P-AAA-Update-Request/Answer messages) by any of the involved parties, e.g., for HAC execution initiated either by the consumer or the TSP/VASP.

3. Third-Party Charging and Billing (3P-C&B)

While the AAA aspect in the service usage is an essential business component and, as indicated above, is essential to the realization of the UCWW environment, it must be supported by associated clearly-defined charging and billing (C&B) mechanisms. In other words, wherever one has the ‘accounting’ of a 3P-AAA system, this must be supported in some way by a C&B system and mechanism. The billing process renders the collected resource/service usage data into a bill. The charging process provides the possibility of controlling the utilization and sharing of network resources, and can be conducted based on (i) the reserved resources; (ii) the actually used resources; and (iii) both the reserved and used resources, [17]. In order to support usage-based charging, the collection of data about the resource reservation, utilization, and usage is required by means of accounting. In general, service providers may use different charging schemes (i.e., instructions for calculating the charge), using tariff variables based on different business models, and may (and frequently do) change those in accordance with their plans so as to distinguish themselves from competitors, [17], increase profit margins, target certain markets, etc. The charging scheme is usually represented by a formula containing different variables (e.g., traffic volume, usage time, reserved peak rate), filled by information from accounting data, and charging coefficients (e.g., price per time unit). The chosen charging scheme(s) influences the provider’s accounting requirements, ranging from zero or only few accounting requirements imposed by flat-rate charging schemes to highly demanding accounting requirements imposed by volume-based charging schemes [17].

Tried and tested C&B mechanisms are in place for the existing SBM-based access networks, both for the fixed and wireless networks. This robust business model, in which the ‛home’ access network has full control over the AAA procedure and the associated C&B subsystem, is in fact one of the main attractions and strengths of these networks for their ANPs [24].

The early data-oriented wireless networks in the legacy SBM environment created their C&B systems using the NAS-based model, which was based on the remote authentication dial-in user service (RADIUS) protocol extensions [25], whereby the charges were calculated by subscription based on either the network usage time or the volume used. This model, however, could not facilitate prepaid C&B systems. In order to fill this gap, the IRTF AAAArch group developed the Diameter Credit-Control (CC) application [20], which can be used to implement real-time credit-control for the usage of different services. This utilizes a generic AAA mechanism for C&B purposes. Nowadays, data-oriented wireless networks by-and-large utilize this C&B framework. Thus, it was also adopted for the 3P-C&B service provision [24] here, although some differences prevail, and extension of the C&B mechanism is required.

3.1. 3P-C&B with Credit Control

The credit-control idea proposed in Reference [20] provides generic credit authorization functionality to prepaid users (with the Diameter vision addressing the legacy SBM requirements, this credit is located within the subscriber’s account in their home ANP) beyond that of the Diameter base protocol [13] in order to enable the rating of service usage in real time and to check whether the funds associated with the user’s account can cover the usage of the requested service.

‘Prepaid-thinking’ has ramifications in the UCWW world which are not present in the legacy subscriber world—in which it usually simply means credit with the subscriber’s home ANP as already indicated. In UCWW, “prepaid” could mean credit with a particular ANP or group of ANPs, or a consortium of ANPs, TSPs, and VASPs who set up a common ‘prepaid’ voucher system between them. This would function somewhat like modern generic vouchers that could be used for buying books, clothes, drinks, or whatever product deemed appropriate in the voucher consortium of shops, restaurants, travel-agents, etc. Consumer credit on their 3P-AAA SP(s) is directly analogous to this ‘generic voucher’. However, in UCWW, there is the potential for a variety of solutions for locating and handling this voucher/consumer-credit system, including locating it on the 3P-AAA-client on the consumer’s mobile device. Whatever solutions are realized, the relevant accounting and C&B solution designs need to match. The development of further details on this is beyond the scope of this article.

When dealing with the simpler SBM-like system of prepaid credit, the task falling to Diameter’s credit control scheme is that when these funds are exhausted, the user must be denied further service usage until credit or funds are topped up. Also, it facilitates a way for the user to be informed of the charges to be applied for the requested service. In addition, provision is made for the user account to be not only debited but also credited, when needed, by services (e.g., advertising or gaming). For this, two new entities are introduced into the AAA infrastructure, namely a CC client and a CC server. Based upon requests sent by CC clients, the CC server performs real-time rating and session-based credit control (by maintaining a session state), involving checking whether credit is available or not, performing credit reservation, making deductions of credit from the user’s account when service usage is completed, performing the refunding of reserved credit that was not used, etc. The Diameter CC application supports operations such as service price inquiries and user balance checks. It also supports flexible failure handling, specific to the credit control supported. There are two credit authorization models specified in Reference [20]: (i) credit authorization with money reservation; and (ii) credit authorization with direct debiting. In both models, a CC client requests credit authorization from the corresponding CC server prior to allowing the user to utilize the service. Both models are utilized for the 3P-C&B service provision.

3.2. 3P-C&B Service Provision Example

The C&B issues in UCWW were initially addressed in References [15,24] by putting forward potential architectural solutions for C&B realization and exploring approaches to the implementation of these novel solutions together with proposing a software testbed for validation and performance evaluation.

Considering the scenario of a consumer in UCWW obtaining service from an ANP/TSP/VASP, the basic accounting and C&B logic flows along the following lines, as originally suggested in Reference [24]. The ‘Class A/B’ 3P-AAA-SP serving the corresponding ANP/TSP/VASP keeps track of the consumer’s service usage and mounting charge (i.e., driven by metering the service or simply by applying a flat charge). At the end of the service session, a bill, accompanied by all the details, is generated by the consumer’s ‘Class C’ 3P-AAA-SP, who pays the service charge indirectly to the corresponding ANP/TSP/VASP through its ‘Class A/B’ 3P-AAA-SP. In scenarios in which problems arise, e.g., the failure of a ‘Class C’ 3P-AAA-SP to pay or a consumer’s overcharging claim, then it is possible to fall back on detailed service usage accounting and charging records. A distribution of the organization and management of this activity between ANPs/TSPs/VASPs, consumers, and 3P-AAA-SPs is required, along with a sharing arrangement.

The development of a generic 3P-C&B architecture employing the Diameter CC concept [20] was initially elaborated upon in References [12,15,24]. A more advanced version of this generic 3P-C&B architecture is expounded upon here, as shown in Figure 7. It includes two main new entities communicating to each other, namely a 3P-C&B server (e.g., located in the 3P-AAA domain and operating on the same machine along with the corresponding 3P-AAA server) and a 3P-C&B client (commissioned near to SE in the ANP/TSP/VASP domain). Communication between a 3P-C&B client and a corresponding 3P-C&B server is indirect via intermediate AAA servers which operate as protocol-transparent Diameter relays. In addition, Diameter redirect agents can be used as a means to refer a 3P-C&B client to the relevant 3P-C&B server. The C&B protocol, used for communication between AAA servers and 3P-C&B servers/clients, is the Diameter base protocol supplemented with a 3P-AAA Diameter application. For redundancy and load balancing, multiple 3P-C&B servers could be deployed as part of this architecture; this is also recommended in Reference [20].

3.3. 3P-C&B Scenarios

Charging and billing interactions are strictly related to the usage of a network access/(value-added) teleservice or to the requested change in QoS, i.e., in the case of a consumer-initiated (or TSP-initiated) HAC. The main 3P-C&B scenarios, envisaged within UCWW [12], are described in the following subsections.

3.3.1. Scenario 1: Network Access Service Usage without HAC

In this scenario, the consumer is charged and billed for the use of a (wireless) network access service of an ANP. Over the 3P-AAA interface d, Figure 8, the interaction is between a ‘Class A’ 3P-AAA-SP and a ‘Class C’ 3P-AAA-SP.

(1)

Start of service session

• Typically, after the mobile device sends an initiation message containing the consumer’s request for usage of a particular service, then the 3P-AAA procedure starts (c.f., Figure 6). After successful completion of this procedure, in the case of a post-paid consumer, session-based credit control (CC) is not required (the 3P-C&B client gets information about that from the ‘Class C’ 3P-AAA server based on the server’s knowledge of the consumer’s payment type), and the service delivery may start immediately.
• If CC is required, then the first CC interrogation is made by the 3P-C&B client (e.g., embedded in SE as shown in Figure 8), before the corresponding SE starts providing the service to the consumer. (The accounting protocol and the CC protocol can be used in parallel, as per the directions given in Reference [20], and as shown in Figure 8.) In the initial Credit Control Request (CCR) message, CCR_Initial, sent by the 3P-C&B client to the ‘Class C’ 3P-C&B server (via the ‘Class A’ 3P-C&B server), the CC-Request-Type AVP is set to the value INITIAL_REQUEST. If the 3P-C&B client knows the cost of the service usage, then the monetary amount to be charged is included in the Requested-Service-Unit AVP; otherwise, the Requested-Service-Unit AVP contains the number of requested service events of type “time”, “volume”, or another service-specific type, as per Reference [20].
• After receiving the CCR_Initial message, the ‘Class A’ 3P-C&B server rates the service event (i.e., converts the requested service units into corresponding monetary units), populates the CCR_Initial message with the amount of requested monetary units, and forwards this message to the corresponding ‘Class C’ 3P-C&B server, belonging to the 3P-AAA-SP serving that particular consumer, in order to make a credit reservation (i.e., reserve the corresponding monetary amount from the consumer’s account) for covering the cost of the requested service event. The type of Requested-Service-Unit AVP in this populated CCR_Initial message is “money”.
• If the ‘Class C’ 3P-C&B server approves the requested credit authorization, then it reserves the relevant monetary amount (e.g., 5 Euro) from the consumer’s account and returns a Credit Control Answer (CCA) message with a Granted-Service-Unit AVP containing this amount to the ‘Class A’ 3P-C&B server, which in turn converts it into the corresponding service units (e.g., one hour of broadband Internet access) and sends a CCA message, containing these units (in the Granted-Service-Unit AVP(s) and other CC-specific AVPs) to the 3P-C&B client. Additionally, the ‘Class A’ 3P-C&B server may set a validity time and may include a Credit-Control-Failure-Handling AVP and a Direct-Debiting-Failure-Handling AVP so as to direct to the client on what to do should the sending of CC messages to it be temporarily prevented, as part of the failure procedure described in Reference [20].
• If the ‘Class A’ 3P-C&B server determines that no further control is needed for the requested service, then it may include a result code indicating that no credit control is applicable (at the command level, this code implies that the credit-control session must be terminated [20]). This may happen when the service is provided free of charge either to all consumers or just to this particular qualifying consumer (e.g., a retired person who is granted limited free-of-charge Internet access). In both cases, this decision is made by the ‘Class A’ 3P-C&B server, but in the latter case (i.e., an individual consumer), this is done after a consultation with the ‘Class C’ 3P-C&B server.
• Upon receiving a CCA message (from the ‘Class A’ 3P-C&B server) with the Granted-Service-Unit AVP(s), the 3P-C&B client grants usage of the service to the consumer (until there is a need to send a new CCR message to the ‘Class C’ 3P-C&B server), and the service session starts.

(2)

During service session

• The 3P-C&B client may generate CCR_Update message(s) when needed during the service session by using the respective CC commands. Regarding the accounting, SE starts sending accounting records (AccRec) to the corresponding ‘Class C’ 3P-AAA server when the service delivery starts and continues to do so whenever needed until the end of the service session, following the recommendations in Reference [20].
• For instance, the 3P-C&B client sends a new intermediate request message (CCR_Update) to the ‘Class C’ 3P-C&B server (via the ‘Class A’ 3P-C&B server) each time all of the granted service units for a particular unit type are (about to be) spent by the consumer or the validity time has expired (this should be done well in advance of the expiration of the previous request so as to avoid interruption of the provision of service). Even if the granted service units reserved by the 3P-C&B server have not been spent upon expiration of the validity time, the 3P-C&B client must send a new CCR_Update request to the server.
• There could also be events occurring in the middle of the service session (e.g., a 3P-AAA update or HAC execution) which might affect the charging of the current service events. In such cases, a new CCR_Update is sent by the 3P-C&B client, including information related to the service event, even if all of the granted service units have not been spent or the validity time has not expired.
• After receiving a new CCR_Update message, the ‘Class A’ 3P-C&B server rates the service event (i.e., converts the requested/used service units into the corresponding monetary units), populates the CCR_Update message with the amount of the requested/used monetary units, and forwards this message to the corresponding ‘Class C’ 3P-C&B server, which deducts/adds the used/unused amount of monetary units from/to the consumer’s account, allocates a new quota as per the newly requested service event, and confirms this by returning a CCA message as a response to the 3P-C&B client.
• There can be several such intermediate interrogations (i.e., several exchanges of CCR_Update/CCA messages) during the service session. A CCA message may include a Final-Unit-Indication AVP or a QoS-Final-Unit-Indication AVP to indicate that it contains the final units for the service, as described in Reference [20].

(3)

End of service session

• With the end of the service delivery, a CCR_Termination message is sent by the 3P-C&B client to the ‘Class C’ 3P-C&B server (via the ‘Class A’ 3P-C&B server) in order to credit the unused units to the consumer’s account and finish the credit-control session.
• On receipt of the CCR_Termination message, the ‘Class A’ 3P-C&B server converts the used service units into corresponding monetary units and forwards the populated CCR_Termination message to the corresponding ‘Class C’ 3P-C&B server to refund the consumer’s account with the unused reserved credit amount.
• When this is accomplished by the ‘Class C’ 3P-C&B server, it acknowledges the session termination by sending back a CCA message as a response to the 3P-C&B client.
• This is followed by sending the final accounting records and a STR/STA message exchange between the SE and the ‘Class C’ 3P-AAA server (via the local AAA server and the ‘Class A’ 3P-AAA server).
• If, during an ongoing service session, the consumer logs off (e.g., a ‘final-unit indication’ causes a consumer’s logoff upon consumption of the final granted units as per the local policy) or becomes inactive for a long period of time, according to application-specific policy, the SE sends a STR message to the corresponding ‘Class C’ 3P-AAA server, which confirms the session termination with a STA message.

3.3.2. Scenario 2: (Value-Added) Teleservice Usage without HAC

In this scenario, the consumer is charged and billed for the use of a (value-added) teleservice provided by an TSP/VASP. During the service session the ANP is not changed. Over the 3P-AAA interface d, the interaction is between a ‘Class B’ 3P-AAA-SP and a ‘Class C’ 3P-AAA-SP. The main signaling between the entities involved in the provision of 3P-C&B in this scenario is similar to that depicted in Figure 8; the only difference is that the ‘Class B’ 3P-AAA-SP takes the place of the ‘Class A’ 3P-AAA-SP.

3.3.3. Scenario 3: (Value-Added) Teleservice Usage with a VASP/TSP-Initiated HAC

In this scenario, the VASP/TSP is charged and billed for any additional network access service costs which may be incurred by a change of access networks when that change is due to an HAC execution initiated and driven by the VASP/TSP. This scenario presumes certain contexts, e.g., that the consumer and VASP/TSP had agreed to a cost-sharing arrangement, perhaps, and, usually, have made this agreement at the beginning of the service session and before VASP/TSP saw that it would have to make this HAC if it was to deliver its teleservice in this instance at an appropriate QoS. This kind of decision-making capacity, for an HAC, would be driven by its QoS policies. This switching of the current network access service session to run over the access network of another ANP, could be for the typical reason that the network access service of the ANP from which the VASP/TSP has decided to switch is unsuitable, e.g., has an inadequate QoS. Over 3P-AAA interface d, the main interactions are between a ‘Class B’ 3P-AAA-SP and two ‘Class A’ 3P-AAA-SPs, e.g., to get the network usage cost information from the ‘old’ and ‘new’ ANP and to calculate the cost difference that needs to be factored in, i.e., covered by TSP/VASP as the one responsible for the HAC.

3.3.4. Scenario 4: (Value-Added) Teleservice Usage with a Consumer-Initiated HAC

In this scenario, the consumer is normally charged and billed for any additional network access service costs arising from an HAC execution which the consumer initiated by changing the ANP for a more suitable network access service. Over 3P-AAA interface d, the main interactions are between a ‘Class C’ 3P-AAA-SP and two ‘Class A’ 3P-AAA-SPs, e.g., to arrange payment (by the ‘Class C’ 3P-AAA-SP on behalf of the consumer) to the ‘old’ ANP for the use of its network access service prior to the HAC execution (which will be perceived by the ANP simply as the termination of the network session) and payment to the ‘new’ ANP for the usage of its network access service from this point onward. While this C&B scenario will require whatever signaling on 3P-AAA interface d it required when setting up the service session with the ‘old’ ANP, before the HAC, it does not impose any new signaling type requirements on the Inter-3P-AAA-SP protocol (c.f., Section 3.4). As implied, this is because, from the viewpoint of the two ANPs involved in such a consumer-initiated HAC, everything looks like the end of a network session for the ‘old’ ANP and the start of a new network session for the ‘new’ ANP. As no specifics are brought in by a consumer-initiated HAC execution, this scenario is similar to Scenario 1 above, i.e., the C&B is identical to the one that would have happened when an ANP was originally selected for the service [12].

3.3.5. One-Time Event Scenarios

In 3P-C&B, one-time event scenarios are also possible (the corresponding messages are shown in italics, blue color in Figure 8). In all of the scenarios listed below, for credit control, there is no need to maintain any state in the corresponding 3P-C&B server, as per the directions in Reference [20].

(1)

Inquiring about the service cost—performed either directly by a C&B client as per Reference [20] or on behalf of a consumer by means of the newly defined 3P-AAA-Service-Cost-Enquiry-Request/Answer messages (c.f., Table 1).

(2)

Verifying that a prepaid consumer’s account balance covers the cost of the requested service (c.f., the observations noted above on prepaid schemes)—performed (without making any credit reservations at the time of the inquiry) either by a C&B client, as in Reference [20], or directly by a consumer through exchanging the newly defined 3P-AAA-Account-Balance-Check-Request/Answer messages (c.f., Table 1) with the corresponding ‘Class C’ 3P-C&B server.

(3)

Refunding/crediting service units to the consumer’s account—initiated either by a C&B client, e.g., for gaming or gambling services as described in Reference [20], or by a ‘Class C’ 3P-AAA server by means of the newly defined 3P-AAA-Account-Credit-Request/Answer messages (c.f., Table 1).

(4)

Direct debiting—performed either by a C&B client without any credit reservations as in Reference [20] or executed by a ‘Class A/B’ 3P-AAA server by means of the newly defined 3P-AAA-Account-Debit-Request/Answer messages (c.f., Table 1).

(5)

Account top-up—initiated either by a C&B client during a graceful service termination as in Reference [20] or by a (prepaid) consumer (at any time) by exchanging the newly defined 3P-AAA-Account-Top-Up-Request/Answer messages (c.f., Table 1) with the corresponding ‘Class C’ 3P-C&B server (or other entity; c.f., observations on prepaid credit above).

(6)

Combined one-time event scenarios—these may include, for instance, checking the account balance followed immediately by direct debiting (without establishing a credit-control session), similarly to what is described in Reference [20] for sending multimedia messaging service (MMS) messages. However, an even more sophisticated use of this is envisaged here for 3P-C&B. For instance, if the account balance check shows that there are insufficient funds remaining in the (prepaid) consumer’s account to send a MMS message, but that the account can cover sending a short messaging service (SMS) message, then the TSP may suggest to the consumer that he/she send only the textual part of his/her MMS message in the form of an SMS message, and, if he/she agrees, then the TSP proceeds with this and instructs its ‘Class B’ 3P-AAA server to request (from the corresponding ‘Class C’ 3P-AAA server) a direct debit from the consumer’s account for that service event. Otherwise, the TSP may inform the consumer of the insufficient credit in his/her account, so that he/she could initiate an account top-up by means of the newly defined 3P-AAA-Account-Top-Up-Request/Answer messages (c.f., Table 1), after which the MMS message could be successfully sent.

3.4. Inter-3P-AAA-SP Protocol

The 3P-C&B is based on: (i) rating and conversion between the service units and the monetary units (conducted entirely on the ‘Class A/B’ 3P-AAA server side and using the corresponding 3P-AAA-SP’s C&B subsystem) and (ii) the consumer being charged and billed via the designated ‘Class C’ 3P-AAA-SP with which the consumer has an account (the consumer may have accounts with multiple ‘Class C’ 3P-AAA-SPs). To support these 3P-C&B interactions between different classes of 3P-AAA-SPs, there is a need to introduce and develop a new signaling protocol—an Inter-3P-AAA-SP protocol, operating over 3P-AAA interface d—whose main signaling operations and flows are illustrated in Figure 9. A Diameter-based implementation of the Inter-3P-AAA-SP protocol has been suggested and designed in Reference [15].

3.5. 3P-C&B for Composite Teleservices

In the case of providing composite teleservices to consumers through different TSPs, one of the strongest envisaged benefits of a mature UCWW environment, smart context-dependent dynamic pricing is required, along with corresponding 3P-C&B provisioning [21]. In order to achieve this, the elaboration of new mechanisms and techniques is needed so as to facilitate the ‘always best servicing’ component of ABC&S depending on the current context. In such composite teleservice delivery, the dynamic QoS monitoring of each component of the composite teleservice is required, along with an ability to dynamically replace/substitute the underperforming component(s) with another one(s) which is(are) currently identified as working better. Such a replacement of teleservice components must be conducted transparently for the providers of these components and seamlessly for the consumers, so that, at most, they may notice only the improvements in the overall teleservice quality received. From the C&B perspective, perhaps the consumer should be supplied with just one itemized bill, provided by the 3P-C&B entity, for the usage of each composite teleservice at the end of the teleservice session. However, this is an open matter which requires addressing as the range of desires of consumers in relation to the potential options here evolve and are better understood.

The trusted third party (TTP) feature of the 3P-C&B entity will facilitate the initial establishment of trust and the subsequent interaction between different providers involved in the composite teleservice provision, e.g., to ensure interoperability with respect to the services/components provided by each of them. This is a challenging task, targeted for future research and development (R&D), which relates to the service intelligent demand shaping (IDS) and service measurement, analytics, and profiling (MAP) tasks [21].

4. Conclusions

Within the environment of a ubiquitous consumer wireless world (UCWW), the form of implementation of trusted third party (TTP) entities providing generic third-party authentication, authorization, and accounting (3P-AAA) and third-party charging and billing (3P-C&B) solutions has been addressed and described in detail with regard to its main novel features and the pathways to its realization. Envisaging implementation–design solutions for these is as important as their realization, along with setting out pathways for the initiation of the associated open global standardization of corresponding interfaces, reference points, and interface protocol messages, for the UCWW coming into existence, as outlined in References [1,2]. The article includes a brief overview of the UCWW global wireless environment concept and its core principles with a focus on these 3P-AAA and 3P-C&B solutions in mind. A full elaboration of UCWW may be found elsewhere, e.g., in References [1,2].

The proposed 3P-AAA and 3P-C&B solutions are first underpinned with descriptions of the main technological foundations of these services, which in turn suggest methods for their provisioning which further ensure that the core principles of UCWW are facilitated and enabled in any implementation design. Key among those principles is ensuring the full mobility of consumers among different (wireless) access networks and access network providers (ANPs) using a single, fully portable consumer identity and thereby granting a consumer device mobility through the attribute of anytime-anywhere-anyhow number portability, which is one of the keys to full consumer-driven always best connected and best served (ABC&S). All of these concepts and more have been elaborated upon elsewhere, e.g., in Reference [1]. Here the specific 3P-AAA and 3P-C&B infrastructural solutions proposed have been designed to serve the UCWW goals, thereby enabling the possibility of realizing authentic global autonomous consumer-driven ABC&S. Hence, the authors particularly stand by the proposed solutions presented here as key to respecting the UCWW goals and principles.

In terms of the 3P-AAA aspect, the hierarchical framework architecture and the reasoning behind it (e.g., including scalability), along with a clearly defined functional model, have been elaborated upon. In the latter functional model, the definitions of ‘the where‘ and ‘the why’ of new interfaces and interface reference points are set out. This includes interfaces with an AAA client installed directly on mobile devices, an approach which would be identified as a complete innovation in the legacy subscriber world. The core principle of UCWW, with its enabling novel 3P-AAA architecture, however, can be seen to readily suggest this innovation. Operationally speaking, the way this AAA client application can be inserted using a smart consumer identity module (CIM) has been set out in the article. The functional model, as presented here, also illustrates and indicates where most of the new signaling requiring global standardization will occur.

One aspect of the functional model proposed here is that it foresees 3P-AAA service providers (3P-AAA-SPs) serving three AAA market sectors. This subdivision of the 3P-AAA is not essential to the nature of UCWW. Rather it is the authors’ suggestion for an orderly organization both of the global standardization process and for those enterprises engaging in implementing and selling 3P-AAA services. It is accepted that others could argue differently.

Our proposal, whether or not there is this sub-division of the three different classes of 3P-AAA-SP, defines new application-layer interfaces which are proposed for global standardization. Full elaboration of the functioning of these interfaces—along with the signaling principles and actual signaling (protocol-message types) utilized on them within a sample of different consumer use cases—for obtaining network access services and other teleservices within the UCWW environment has been presented. This is achieved by drawing fully on existing AAA solutions in the legacy networks, e.g., IETF’s Diameter. The 3P-AAA protocol stack and policy-based accounting and its operation are elaborated on, including three potential ‘authorization models’ and their accompanying signaling, with a specific recommendation of the pull model as the most efficient and the push model which is perhaps more in keeping with the UCWW goal of pushing more control (e.g., consumer-driven ABC&S) into the hands of the consumer, along with more intelligence to the network edge (i.e., into the consumer’s mobile device domain). The example signaling flow diagrams presented cover the rather straightforward use cases of the consumer utilizing the teleservice of a single teleservice provider (TSP) through the access network of a single access network provider (ANP). Notably, this uncomplicated operational scenario does yield a complex enough illustration. Therefore, more complex scenarios, e.g., one in which a consumer-driven (or TSP-driven) hot access network change (HAC) occurs, are not diagrammatically presented, though the approach towards handling the signaling for such complex scenarios is indicated sufficiently for the reader to create their own signaling flow diagrams. The description also includes a new Inter-3P-AAA-SP signaling protocol whose role is to facilitate the accounting and charging (3P-C&B) interactions between entities from the three different classes of 3P-AAA-SPs—the pathway for the 3P-AAA-SP development proposed in this article. If this pathway is endorsed by the industry, by their express desire to develop the market along such lines, as we have recommended, naturally such a protocol will then have to be part of an open global standard.

The 3P-AAA section is followed by a matching elaboration of the associated 3P-C&B service. C&B is always linked to the accounting aspect of AAA. The presentation here includes detailed examples of related C&B signaling scenarios, which, while not comprehensive, are quite indicative, offering a clear comprehensible template for the development of the necessary signaling in more complex service scenarios, which would not be feasible in an article like this. Good focus is laid on the important area of consumer credit, its control, and how this is analogous to subscriber prepayment credit and its management in today’s legacy networks. Ideas on how this plays out in terms of innovations to the legacy credit authorization and control solutions, i.e., beyond that envisaged for the Diameter protocol, together with new signaling messages over the proposed new signaling interfaces, are presented with illustrative examples.

Finally, the concepts and examples presented in this article are by no means exhaustive but are illustrative. It is clear from the ideas and content here that the field is ripe for wide-scale R&D which would feed into the relevant UCWW global standardization process.