HK1217144A1

HK1217144A1 - Diameter/xml protocol conversion

Info

Publication number: HK1217144A1
Application number: HK16105110.6A
Authority: HK
Inventors: 梅格哈斯瑞．科達拉古德; 梅格哈斯瑞．科达拉古德; 陳振豪; 陈振豪; 穆泰俄赫．溫卡塔查拉姆; 穆泰俄赫．温卡塔查拉姆
Original assignee: 英特尔Ip公司
Priority date: 2013-04-26
Filing date: 2014-03-28
Publication date: 2016-12-23
Also published as: US20160227166A1; CN105052109A; EP2989827B1; CN105340327A; CN105103626A; CN105052202B; TW201728165A; KR102063460B1; EP2989734A4; TW201507480A; TW201611634A; JP2016521395A; TW201446026A; US9307192B2; EP2989830A1; EP2989833A1; US9621845B2; WO2014175999A1; KR20170010448A; EP2989829A1

Abstract

Embodiments of protocol converters (PCs), and related techniques, are disclosed herein. In some embodiments, a PC may include reception logic to receive Extensible Markup Language (XML) data transmitted by an Application Function (AF), conversion logic to convert the XML data into a Diameter Protocol (DP) message, and provision logic to provide the DP message for transmission to a Policy and Charging Rules Function (PCRF). Other embodiments may be disclosed and/or claimed.

Description

Diameter/XML protocol conversion

Cross Reference to Related Applications

This application claims priority to U.S. provisional application entitled "advanced wireless communication system and technology", filed 2013, 26/4/2013, and having application number 61/816,662, the entire contents of which are incorporated herein by reference.

Technical Field

Embodiments of the present disclosure relate generally to wireless communications and, more particularly, to Diameter/extensible markup language (XML) protocol conversion.

Background

The Diameter Protocol (DP) is an authentication, authorization, and accounting protocol used in some computer networks. In the third generation partnership project (3GPP) wireless communication standard, DP is used to send messages between an Application Function (AF) and a Policy and Charging Rules Function (PCRF). The AF is an element that provides applications that use Internet Protocol (IP) bearer resources and typically includes third party network application providers. The PCRF is an element that supports the following functions: policy control decisions and flow-based charging control, the PCRF may use information from the subscription database as a basis for the policy and charging control decisions. DP messages between AF and PCRF are transmitted over the Rx interface. However, third party web application providers are generally more familiar with the extensible markup language (XML) protocol than DP; therefore, requiring the AF to transmit a DP message may hinder development of the AF.

Drawings

The embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are shown by way of example and not by way of limitation in the figures of the accompanying drawings.

Fig. 1 is a block diagram of a portion of a wireless communication system including a Protocol Converter (PC), in accordance with various embodiments.

Fig. 2 is a block diagram of a PC according to various embodiments.

Figure 3 is a diagrammatic representation of a Diameter Protocol (DP) message in accordance with various embodiments.

Fig. 4 is a diagrammatic representation of an attribute-value pair (AVP) in accordance with various embodiments.

FIG. 5 is a diagrammatical representation of extensible markup language (XML) data in accordance with various embodiments.

Fig. 6 is a flow diagram of an exemplary process for providing a DP message based on received XML data, in accordance with various embodiments.

Fig. 7 is a flow diagram of an exemplary process for providing XML data based on a received DP message, in accordance with various embodiments.

Fig. 8-11 depict various arrangements of PCs within a wireless communication system, in accordance with various embodiments.

FIG. 12 is a block diagram of an exemplary computing device that may be used to implement various embodiments described herein.

Detailed Description

Embodiments of a Protocol Converter (PC) and techniques related thereto are disclosed herein. In some embodiments, a PC may receive extensible markup language (XML) data communicated by an Application Function (AF) and may generate a Diameter Protocol (DP) message for communication to a Policy and Charging Rules Function (PCRF) based at least in part on the received XML data. The XML data (received and/or generated by the PC) may include an attribute-value pair (AVP) element, and the AVP element includes an AVP parameters element, which may include a first XML element representing an attribute-value pair (AVP) encoding, a second XML element representing an AVP flag, and a third XML element representing an AVP length.

The PC disclosed herein may map XML data to DP messages (and/or vice versa). This may enable the AF to communicate XML data to the PCRF instead of DP messages. Since the XML protocol may be more familiar to third party web application providers, the ability to transmit XML data rather than DP messages may facilitate the development of web applications. In addition, by providing translation capabilities between XML data and DP messages, the PC disclosed herein may enable AFs to communicate XML data without requiring the PCRF to understand the XML data, thus reducing disruption to existing DP-based PCRF signaling mechanisms.

In some embodiments, XML data transmitted by the AF to the PC (for provision to the PCRF) may be formatted according to an XML schema (schema) that enables the XML data to be readily converted into DP messages. Some of these formats may have particularly efficient conversion characteristics that reduce the amount of data that must be transferred between the AF and the PC in order to form an efficient DP message. These formats may take advantage of various characteristics of the XML schema to provide efficient performance. Similarly, a PC configured to convert DP messages into XML data may utilize this schema to generate XML data based on DP messages to formally transfer information from the PC to the AF. Various examples of techniques for converting XML data into DP messages are disclosed herein; a complement to either of these techniques can be readily implemented to convert DP messages into XML data. Similarly, multiple examples of techniques for converting DP messages into XML data are disclosed herein; a complement to either of these techniques can be readily implemented to convert XML data into DP messages.

Various operations may be described as multiple discrete acts or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of mention. In further embodiments, various additional operations may be performed and/or the operations described may be omitted.

For the purposes of this disclosure, the phrase "a and/or B" refers to (a), (B), or (a and B). For the purposes of this disclosure, the phrase "A, B, and/or C" refers to (a), (B), (C), (a and B), (a and C), (B and C), or (A, B and C). The description may use the phrases "in one embodiment" or "in an embodiment," each of which may refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are intended to be synonymous.

As used herein, the term "logic" may refer to, be part of, or include the following: an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality.

Fig. 1 is a block diagram of a portion of a wireless communication system 100 in accordance with various embodiments. The portion of the wireless communication system 100 shown in fig. 1 may be a portion of a wireless communication system configured according to a 3GPP wireless communication standard; for ease of description, many components of the 3GPP wireless communication system are omitted from fig. 1, but may be included in the wireless communication system 100. The wireless communication system 100 may include an Application Function (AF)102, a Protocol Converter (PC)104, and a Policy and Charging Rules Function (PCRF) 106.

As mentioned above, the AF102 may provide applications or the like that use IP bearer resources. The AF102 may communicate with the PC104 via a communication link 108. The communication link 108 may be a two-way communication link that allows the AF102 to send data to the PC104, and vice versa. In some embodiments, the communication link 108 may comprise a wireless communication link, a wired communication link, or a combination of wired and wireless links. Additional components may be included in communication link 108. In addition to the XML data based signaling techniques disclosed herein, the AF102 may be configured in accordance with conventional AFs as described in the 3GPP wireless communication standards.

As mentioned above, PCRF106 may support policy control decision making and flow-based charging control functions, among others. PC104 may communicate with PCRF106 via communication link 110. Communication link 110 may be a bi-directional communication link allowing PC104 to send data to PCRF106 and vice versa. In some embodiments, the communication link 108 may comprise a wireless communication link, a wired communication link, or a combination of wired and wireless links. Additional components may be included in communication link 110. In addition to communication between PCRF106 and PC104, PCRF106 may be configured as a conventional PCRF as described in the 3GPP wireless communication standard.

Fig. 2 is a block diagram of a PC104 according to various embodiments. As mentioned above, PC104 may be configured to receive XML data, convert the received XML data into a DP message, and provide the DP message to PCRF 106. Additionally or alternatively, the PC104 may be configured to receive DP messages, convert the received DP messages into XML data, and provide the XML data to the AF 102.

The PC104 may include receive logic 202. In some embodiments, the receiving logic 202 may be configured to receive XML data transmitted by the AF 102. In some embodiments, the reception logic 202 may be configured to receive DP messages transmitted by the PCRF 106. In some embodiments, the reception logic 202 may be configured to receive both XML data (e.g., transmitted by the AF 102) and DP messages (e.g., transmitted by the PCRF 106). In some embodiments, the receive logic 202 may include a first set of logic to receive XML data and a second set of logic different from the first set of logic to receive DP messages. In some embodiments, the receive logic 202 may be configured to receive XML data or DP messages, but not both.

The reception logic 202 may receive the XML data transmitted by the AF102 in any of a variety of ways (e.g., any of the ways discussed above with respect to the communication link 108). For example, the receive logic 202 may be coupled with an antenna 208. In some embodiments, the XML data received by the receive logic 202 may be wirelessly transmitted from the AF102 to the PC104 via the antenna 208. The reception logic 202 may receive the DP messages transmitted by the PCRF106 in any of a variety of ways (e.g., any of the ways discussed above with respect to the communication link 110). For example, in some embodiments, DP messages received by receive logic 202 may be wirelessly communicated from PCRF106 to PC104 via antenna 208. In some embodiments, PC104 may include a different antenna or other communication interface for receiving XML data and for receiving DP messages. As mentioned above, in some embodiments, the receive logic 202 may be configured to receive XML data or DP messages, but not both.

The PC104 may include conversion logic 204. In some embodiments, the conversion logic 204 may be configured to convert XML data received by the reception logic 202 into DP messages. In some embodiments, the conversion logic 204 may be configured to convert DP messages received by the reception logic 202 into XML data. In some embodiments, the conversion logic 204 may be configured to convert XML data to DP messages and to convert DP messages to XML data. In some embodiments, the conversion logic 204 may include a first set of logic to convert XML data into DP messages and a second set of logic different from the first set of logic to convert DP messages into XML data. In some embodiments, the conversion logic 204 may be configured to convert XML data to DP messages or DP messages to XML data, but not both.

The PC104 may include provisioning (provision) logic 206. In some embodiments, the provisioning logic 206 may be configured to provision the DP messages generated by the translation logic 204 for transmission to the PCRF 106. In some embodiments, the provision logic 206 may be configured to provide the XML data generated by the conversion logic 204 for transmission to the AF 102. In some embodiments, provisioning logic 206 may be configured to provision both DP messages (e.g., for communication to PCRF 106) and XML data (e.g., for communication to AF 102). In some embodiments, the provision logic 206 may include a first set of logic for providing XML data and a second set of logic different from the first set of logic for providing DP messages. In some embodiments, the provision logic 206 may be configured to provide DP messages or XML data, but not both.

The DP message generated by translation logic 204 may be provided by provisioning logic 206 in any of a variety of ways (e.g., in any of the ways discussed above with respect to communication link 110). For example, the provision logic 206 may be coupled with the antenna 208 (or another antenna) and may provide the DP message for wireless transmission to the PCRF106 via the antenna 208 (or other antenna). The provision logic 206 may provide the XML data generated by the conversion logic 204 in any of a variety of ways (e.g., any of the ways discussed above with respect to the communication link 108). For example, in some embodiments, the provision logic 206 may be coupled with the antenna 208 (or another antenna) and may provide XML data for wireless transmission to the AF102 via the antenna 208 (or other antenna). In some embodiments, PC104 may include different antennas or other communication interfaces for providing DP messages and providing XML data. As mentioned above, in some embodiments, the provision logic 206 may be configured to provide XML data or DP messages, but not both.

The PC104 may include a memory 208. The memory 208 may be coupled to any one or more of the receive logic 202, the convert logic 204, and the provide logic 206, and may be configured to store any data related to the operation of any of the logic included in the PC 104. For example, in some embodiments, the memory 208 may store XML data and/or DP messages received by the receive logic 202. In some embodiments, memory 208 may store one or more XML schemas and/or transformation rules for generating XML data based on DP messages and/or generating DP messages based on XML data. In some embodiments, memory 208 may store XML data and/or DP messages generated by provisioning logic 206 (based on received DP messages and/or XM data, respectively).

Fig. 3 is a diagrammatic representation of a DP message in accordance with various embodiments. In some embodiments, DP message 300 may be generated by translation logic 204 of PC104 (based on XML data received by reception logic 202) and provided by provisioning logic 206 for transmission to PCRF 106. In some embodiments, DP message 300 may be received by receive logic 202 and converted to XML data by convert logic 204. The form of DP message 300 may be conventional and is briefly described herein for ease of illustration.

DP message 300 may be a request message or a reply message (such as an AA request (AARequest) or AA reply (AAAnswer) message) that may include a header 302 and one or more attribute-value pairs (AVPs) 304. As shown in fig. 3, the header 302 may include a version field and a message length field in the first 32 bits. The next 32 bits of the header 302 may include a plurality of flags, such as a request (R) flag, a Proxiable (P) flag, an error (E) flag, and a possible retransmit message (T) flag. When the R flag is set, it indicates that DP message 300 is a request (otherwise, a reply). When the P flag is set, it indicates that DP message 300 may be proxied, relayed, or redirected (otherwise must be processed locally). When the E flag is set, it indicates that the DP message contains a protocol error. When the T flag is set, it indicates that a connection failover process has occurred. The header 302 may also include a command code field, an application ID field, a hop-by-hop ID field, and an end-to-end ID field.

One or more AVPs 304 included in DP message 300 may provide additional data. In some embodiments, DP message 300 must include at least one AVP 304. Figure 4 is a diagrammatic representation of an AVP400 according to various embodiments. In some embodiments, AVP400 may be included in DP message 300. The form of the AVP400 may be conventional and is briefly described herein for ease of illustration.

The AVP400 may include a header 402 and data 404. As shown in fig. 4, the first 32 bits of the AVP may be an AVP code field. The next 32 bits of the AVP400 may include a plurality of flags, such as a vendor specific (V) flag, a mandatory (M) flag, and a protect (P) flag. When the V flag is set, it indicates that the AVP400 includes the vendor ID field in bits 64-95. When the M flag is set, it indicates that support of the AVP400 is required to accept the DP message 300. When the P flag is set, it indicates the need for end-to-end encryption. The second 32 bits of the AVP may also include an AVP length field. As shown in fig. 4, the AVP400 may also include a vendor ID field (as discussed above), as well as data 404.

Fig. 5 is a diagrammatic representation of XML data 500 in accordance with various embodiments. In some embodiments, the XML data 500 may be received by the receive logic 202 of the PC104 and converted to a DP message by the convert logic 204. In some embodiments, the XML data 500 may be generated by the conversion logic 204 (based on the DP message received by the reception logic 202) and provided by the provision logic 206 for transmission to the AF 102.

The XML data 500 may include one or more elements. As shown in FIG. 5, XML data 500 may include elements 502, 504, 506, 508, 510, and 512. Some elements, such as elements 502 and 512, may be independent elements and may not be nested to other elements, nor may they include nested elements. Some elements, such as elements 504 and 508, may include additional nested elements. In FIG. 5, element 504 includes nested elements 506, 508, and 510. Because element 510 is included in element 508, and element 508 is included in element 504, element 510 is nested twice inside element 504.

In some embodiments, the receiving logic 202 is configured to receive XML data transmitted by the AF102, and the converting logic 204 is configured to convert the XML data into DP messages, which may be organized using a predetermined format. This format may be defined by an XML schema known to the AF102 and PC 104. A variety of such formats are disclosed herein. Various ones of these formats may be recognized by the conversion logic 204 and may enable the conversion logic 204 to efficiently convert XML data into DP messages.

In some embodiments, the XML data received by the receive logic 202 from the AF102 may include AVP elements. The AVP element of the XML data may correspond to the AVP of the DP message (e.g., AVP400 of DP message 300). In some embodiments, the translation logic 204 may translate data included in the AVP element of the received XML data into a component of the AVP of the DP message (for provision by the provisioning logic 206 to the PCRF 106).

In some embodiments, the AVP element included in the XML data may include one or more additional elements. For example, the AVP element may include an element representing an AVP code. The AVP elements may include elements representing one or more AVP flags. The AVP element may include an element representing the length of the AVP. In some embodiments, the AVP elements included in the XML data may include an element representing an AVP code, an element representing one or more AVP flags, and an element representing an AVP length. Each of these elements included in the AVP element may correspond to a component of the AVP of the DP message. For example, the translation logic 204 may be configured to identify data included in an element representing the AVP code and provide this data (or its equivalent) in the AVP code field of the AVP 400. The conversion logic 204 may be configured to identify data included in elements representing one or more AVP flags and provide this data (or its equivalent) as a flag in the AVP 400. The conversion logic 204 may be configured to identify data included in an element representing the length of the AVP and provide this data (or its equivalent) in the AVP length field of the AVP 400.

In some embodiments, the AVP element may include an AVP parameters (AVP-Parameter) element that itself includes an element representing the AVP code, an element representing one or more AVP flags, and an element representing the AVP length. In other words, an element representing the AVP code, an element representing one or more AVP flags, and an element representing the AVP length may be nested in an AVP parameters element, which may be nested in an AVP element. In this way, the AVP parameters element may "group" elements representing an AVP code, one or more AVP flags, and an AVP length. In some embodiments, the AVP parameters elements included in the XML data may take the form shown below in table 1.

TABLE 1

As shown, the AVP parameter elements of table 1 include an element representing an AVP code, an element representing an AVP flag, and an element representing an AVP length. In some embodiments, each valid AVP element included in the XML data received by the reception logic 202 may include an AVP parameters element including: (1) an element representing an AVP code; (2) elements representing one or more AVP flags; (3) an element representing the length of the AVP (e.g., the AVP parameters element of table 1). The AVP parameters element may be a required element of the AVP element according to an XML schema that defines valid AVP elements.

In some embodiments, the AVP element may be included in the XML data via a reference attribute (referrentiattribute) in the XML schema. For example, the XML data included in table 2 may correspond to AVPs that provide Session ID information (e.g., Session-ID element of AVP code 260 corresponding to DP). The session IDAVP may be included in an AA request message transmitted via the Rx interface, for example:

TABLE 2

As shown in table 2, the session IDAVP element includes the AVP parameter element of table 1 by referring to the attribute. For each representative AVP element in the XML schema, the use of the AVP parameters element may reduce the size of the XML representation of the DP message as compared to explicitly including elements in the AVP parameters element (e.g., code, flags, and length elements). In some embodiments, each valid AVP element included in the XML data may include an AVP parameters element.

The session IDAVP element shown in Table 2 is merely an example of an AVP element that may be included in XML data and may be identified by conversion logic 204 when generating a DP message based on the XML data. Table 3 below lists examples of a number of AVP elements that may be included in the XML data provided by the AF 102. In the first column of Table 3, a list of AVP types is provided, corresponding to known AVP types in DP. In the second column of table 3, the DP code associated with each known AVP type is provided. In the third column of Table 3, a known DP data type for each known AVP type is provided. In the fourth column of Table 3, the data types for AVP elements in the XML schema that correspond to different known AVP types are provided. The data type provided in the fourth column of table 3 may provide an appropriate match to the data type provided in the third column of table 3, which enables AVP information to be transferred and converted to AVPs in DP messages in XML data.

TABLE 3

Some DPAVPs may include or be associated with other AVPs. Table 4 below lists examples of these AVP elements associated with a media component description (MediaComponentDescription) AVP that may be included with the XML data provided by AF 102. The definition of the columns of table 4 is the same as described above with reference to table 3.

TABLE 4

Table 5 below lists the number of examples of AVP elements that are associated with a subscriber (subscription) IDAVP that may be included in the XML data provided by the AF 102.

TABLE 5

Table 6 below lists the number of examples of AVP elements associated with supported feature (SupportedFeature) AVPs that may be included in the XML data provided by the AF 102.

TABLE 6

Table 7 below lists the number of examples of AVP elements associated with the initiated connection (spoonsoredconnection) AVP that may be included in the XML data provided by the AF 102.

TABLE 7

Table 8 below lists the number of examples of AVP elements associated with an authorization service unit (GrantedServiceUnit) AVP that may be included with the XML data provided by the AF 102.

Authority service Unit (AVP)	AVP code	Diameter data type	XML schema
				Tariff Time Change	451	Time	Time
CC-Time	420	Unsigned#2	UnsignedInt
				CC-Money	413	Grouped	Group
Total Octets	421	Unsigned64	UnsignedInt
				Input Octets	412	Unsigned64	UnsignedInt
Output Octets	414	Unsigned64	UnsignedInt
				Service Specific Units	417	Unsigned64	UnsignedInt

TABLE 8

Table 9 below lists the number of examples of AVP elements associated with the used service unit (UsedServiceUnit) AVP that may be included in the XML data provided by the AF 102.

TABLE 9

Table 10 below lists the number of examples of AVP elements that are associated with CC-MoneyAVP that may be included with the XML data provided by the AF 102.

Watch 10

Table 11 below provides elements of XML data that may correspond to a header of a DP message (e.g., header 302 of DP message 300 of fig. 3). The XML data received by the reception logic 202 may include the XML data elements of table 11, and the conversion logic 204 may convert the XML data elements of table 11 into a DP header, which may be included in a DP message for transmission to the PCRF 106.

TABLE 11

Table 12 below provides AVP elements of XML data that may correspond to various AVPs of the DP. The XML data received by the reception logic 202 may include one or more AVP elements of table 11, and the conversion logic 204 may convert the AVP elements of the XML data to AVPs, which may be included in DP messages for transmission to the PCRF 106. The AVP to which each AVP element in table 12 can be converted is identified by the name of the XML element.

TABLE 12

As represented in table 12, each XML element corresponding to an AVP may include an AVP parameters element (which, as discussed above, may itself include an element representing an AVP code, an element representing an AVP flag, and an element representing an AVP length). The XML elements of the plurality of tables 12 are of the "group" type that includes other XML elements. For example, the media component description element, the subscriber ID element, the supported features element, the originating connection data element, and the proxy information element may have a group type. Elements included in other XML elements may also have a group type. For example, the initiate connection data element may include an authorization service group element and a user service group element, and each of the authorization service group element and the user service group element may have a group type. In another example, the authorization service group element and the user service group element may each comprise a funds group (MoneyGroup) element, and the funds group element may have a group type.

In some embodiments, the XML expressions discussed with respect to tables 1-12 may represent valid forms of XML data received by the receive logic 202 for conversion into DP messages by the convert logic 204. In some embodiments, the XML expressions discussed with respect to tables 1-12 may represent the form of XML data generated by the conversion logic 204 based on DP messages received by the reception logic 202. The mapping between XML data elements and components of the DP message is labeled in tables 1-12. The XML expressions discussed with respect to tables 1-12 are not exhaustive, and additional XML data elements may be defined to correspond to additional DP message components in accordance with the schema illustrated in tables 1-12 and the techniques discussed herein.

Fig. 6 and 7 are flowcharts of exemplary processes that may be performed by PC104, in accordance with various embodiments. In some embodiments, PC104 may be configured to perform the process represented in fig. 6 and the process represented in fig. 7. In some embodiments, the PC104 may be configured to perform one of the processes represented in fig. 6 and 7, but not both.

Fig. 6 is a flow diagram of an exemplary process 600 for providing a DP message based on received XML data, in accordance with various embodiments. In operation 602, the PC104 may receive XML data transmitted by the AF 102. In some embodiments, operation 602 may be performed by the receive logic 202 of the PC 104. In some embodiments, the XML data received at operation 602 may take the form of any of the embodiments discussed above with respect to FIGS. 1-12. In some embodiments, the XML data may include an AVP element, and the AVP element may include a first XML element representing an AVP code, a second XML element representing an AVP flag, and a third XML element representing an AVP length.

At operation 604, the PC104 may convert the XML data (received at operation 602) into a DP message. In some embodiments, operation 604 may be performed by the translation logic 204 of the PC 104. For example, the mapping between the components of the received XML data and DP messages may take the form of any of the embodiments discussed above with respect to FIGS. 1-12.

At operation 606, PC104 may provide the DP message (generated at operation 604) to PCRF 106. In some embodiments, operation 604 may be performed by provisioning logic 206 of PC 104. Process 600 may then end.

Fig. 7 is a flow diagram of an exemplary process 700 for providing XML data based on a received DP message in accordance with various embodiments. At operation 702, PC104 may receive a DP message transmitted by PCRF 106. In some embodiments, operation 702 may be performed by the receive logic 202 of the PC 104.

At operation 704, the PC104 may convert the DP message (received at operation 702) into XML data. In some embodiments, operation 704 may be performed by the translation logic 204 of the PC 104. For example, the mapping between the received DP message and the XML data elements may take the form of any of the embodiments discussed above with respect to fig. 1-12.

At operation 706, the PC104 may provide the XML data (generated at operation 704) to the AF 102. In some embodiments, operation 706 may be performed by provisioning logic 206 of PC 104. In some embodiments, the XML data provided at operation 706 may take the form of any of the embodiments discussed above with respect to FIGS. 1-12. In some embodiments, the XML data may include an AVP element, and the AVP element may include a first XML element representing an AVP code, a second XML element representing an AVP flag, and a third XML element representing an AVP length. Process 700 may then end.

The logical location of the PC104 in the wireless communication system 100 may be different in different embodiments. Fig. 8-11 depict various arrangements of a PC within a wireless communication system, in accordance with various embodiments.

In arrangement 800 of fig. 8, PC104 may be configured to operate within a Diameter realm (realm) that includes PCRF 106. In figure 8, two Diameter realms 118 and 120 are depicted within a 3GPP Public Land Mobile Network (PLMN). Each of Diameter realms 118 and 120 may include one or more of PCRF106, Diameter Routing Agent (DRA)114, and PC 104. PCRF106 included in the Diameter realm may be individually addressable, and a session between AF102 and a particular PCRF of PCRF106 in the Diameter realm may be maintained by DRA 114. In particular, DRA114 may maintain the state of assigned PCRF106 for certain User Equipment (UE) and IP connectivity access network (IP-CAN) sessions. In addition to communication between DRA114 and PC104, DRA114 may be configured according to a conventional DRA as described in the 3GPP wireless communication standard. The AF102 may be configured to operate within the AF domain 116. In arrangement 800, PC104 may be configured to receive XML data from AF102 via communication link 108 and convert the XML data into one or more DP messages for provision to DRA114 via communication link 112. DRA114 may route the DP message to the appropriate PCRF106 (via communication link 124). In some embodiments, PC104 of arrangement 800 may be configured to receive one or more DP messages from PCRF106 (via DRA114 and communication links 124 and 112) and convert the one or more DP messages into XML data for provision to AF102 (via communication link 108). In some embodiments, the communication links 108, 112, and 124 may be included in the Rx interface.

The arrangement 800 may have a number of advantages. By placing the PC104 inside the 3GPP plmn at the entry point of the 3GPP domain, little or no changes may need to be made to the 3GPP architecture (within the 3GPP plmn 122) in order to accommodate the XML data translation functionality. The third party application provider may not need to employ or otherwise incorporate additional hardware and/or software to implement the PC104, which makes the use of the conversion function quick and easy. Because the PC104 is included in the 3GPP architecture, the operation and characteristics of the PC104 can be standardized as part of the 3GPP communication standard, and the interaction between the AF102 and the PC104 can be easily managed by the operator of the PLMN 122. However, these advantages may be balanced against the additional standardization effort required to fully specify the operation and characteristics of the PC104 within the 3GPP wireless communication standard.

In the arrangement 900 of fig. 9, the PC104 may be configured to operate within the domain 116 of the AF 102. Communications between the AF102 and the PC104 may be performed in accordance with any desired interface, such as a proprietary interface. In some embodiments, the communication between AF102 and PC104 may be performed in a manner compatible with standards of XML format (xmlformatsformingresourcelists) for expressing resource lists proposed by the Internet Engineering Task Force (IETF) in 5 months 2007. In arrangement 900, PC104 may be configured to receive XML data from AF102 via communication link 108 and convert the XML data into one or more DP messages for provision to DRA114 via communication link 112. DRA114 may route (via communication link 124) the DP message to the appropriate PCRF 106. In some embodiments, PC104 of arrangement 800 may be configured to receive one or more DP messages from PCRF106 (via DRA114 and communication links 124 and 112) and convert the one or more DP messages into XML data for provision to AF102 (via communication link 108). In some embodiments, the communication links 112 and 124 may be included in the Rx interface. Other components of the arrangement 900 may take the form of corresponding components described above with respect to fig. 8.

Arrangement 900 may have a number of advantages. By placing the PC104 within the AF domain 116, little standardization effort needs to be performed in order to incorporate the functionality of the PC104 into the 3GPP wireless communication standard, offloading the implementation to the third party AF domain 116. However, the third party application provider must implement the functionality of the PC104, which may compromise the benefits obtained by allowing XML data to be transmitted to the PC104 instead of DP messages. Placing the PC104 in the AF domain 116 may open up the possibility of many non-standardized variants of the PC104, which may make managing the AF102 using such a PC104 more complex. Additionally, because PC104 of arrangement 900 may serve more than one Diameter realm (e.g., Diameter realms 118 and 120), PC104 may require addressing functionality to route information to and/or from the appropriate Diameter realms.

In the arrangement 1000 of fig. 10, the PC104 may be configured to operate outside the AF domain 116 and outside the PLMN 122. In the arrangement 1000, the PC104 may "bridge" the AF domain 116 and the 3GPP domain represented by the PLMN 122. In arrangement 1000, PC104 may be configured to receive XML data from AF102 via communication link 108 and convert the XML data into one or more DP messages for provision to DRA114 via communication link 112. DRA114 may route (via communication link 124) the DP message to the appropriate PCRF 106. In some embodiments, PC104 of arrangement 800 may be configured to receive one or more DP messages from PCRF106 (via DRA114 and communication links 124 and 112) and convert the one or more DP messages into XML data (via communication link 108) for provision to AF 102. In some embodiments, communication links 112 and 124 may be included in the Rx interface. Other components of the arrangement 1000 may take the form of corresponding components described above with respect to fig. 8.

Arrangement 1000 may have a number of advantages. By placing the PC104 outside the PLMN122, little standardization work needs to be performed in order to incorporate the functionality of the PC104 into the 3GPP wireless communication standard. Additionally, the third party application provider may not need to employ or otherwise incorporate additional hardware and/or software to implement the PC104, which makes the adoption of the conversion function quick and easy. However, placing the PC104 outside of the PLMN122 may open up the possibility of many non-standardized variations of the PC 104. This may make the management of the AF102 using such a PC104 more complicated. Additionally, because PC104 of arrangement 1000 may serve more than one Diameter realm (e.g., Diameter realms 118 and 120), PC104 may require addressing functionality to route information to and/or from the appropriate Diameter realms.

In arrangement 1100 of fig. 11, multiple PCs (104a, 104b, and 104c) may be configured to operate within Diameter realm 126 that does not include PCRF 106. In figure 11, three Diameter realms 118, 120, and 126 are depicted within the PLMN 122. Each of Diameter realms 118 and 120 may include one or more of PCRF106 and DRA 114. PCRF106 included in Diameter realms 118 and 120 may be independently addressable, and within Diameter realms 118 and 120, sessions between AF102 and particular ones of PCRF106 may be maintained by DRA114 (as discussed above with respect to figure 8). The AF102 may be configured to communicate (via communication link 108) with each of the PCs 104a, 104b, and 104 c. Each of PCs 104a, 104b, and 104c may be configured to communicate with DRA114 within Diameter realm 118 and DRA114 within Diameter realm 120. In arrangement 1100, any of PCs 104a, 104b, and 104c may be configured to receive XML data from AF102 via communication link 108 and convert the XML data into one or more DP messages for provision to DRA114 (within Diameter realm 118 or within Diameter realm 120) via communication link 112. DRA114 may route (via communication link 124) the DP message to the appropriate PCRF 106. In some embodiments, any of PCs 104a, 104b, and 104c of arrangement 1100 may be configured to receive (via respective DRAs 114 and communication links 124 and 112) one or more DP messages from PCRF106 and convert the one or more DP messages into XML data (via communication link 108) for provision to AF 102. In some embodiments, the communication links 108, 112, and 124 may be included in the Rx interface.

The arrangement 1100 may have a number of advantages (e.g., those described above with respect to fig. 8), but may be balanced against the additional standardization effort required to fully specify the operation and characteristics of the PCs 104a, 104b and 104c within the 3GPP wireless communication standard.

FIG. 12 is a block diagram of an exemplary computing device 1200, which may be suitable for practicing the various disclosed embodiments. For example, computing device 1200 may operate as (or otherwise support) AF102, PC104, PCRF106, or any other suitable device discussed herein. The computing device 1200 may include a number of components, including one or more processors 1204 and at least one communication chip 1206. In various embodiments, processor 1204 may comprise a processor core. In various embodiments, the at least one communication chip 1206 may also be physically and electrically coupled to the processor 1204. In further implementations, the communication chip 1206 may be part of the processor 1204. In various embodiments, the computing device 1200 may include a PCB 1202. For these embodiments, the processor 1204 and the communication chip 1206 may be disposed thereon. In alternative embodiments, the various components may be coupled without the use of the PCB 1202. In some embodiments, computing device 1200 may be a server computing device, or any other electronic device that processes data. In particular, in some embodiments, computing device 1200 providing PC104 may be a server computing device (e.g., a network server capable of load balancing and other common functions) that can be configured to handle the desired communication protocol.

The computing device 1200 may include other components, which may or may not be physically and electrically coupled to the PCB 1202. These components may provide some or all of the data storage and communication functionality of the various computing devices disclosed herein (e.g., PC 1). These other components may include, but are not limited to, volatile memory (e.g., Dynamic Random Access Memory (DRAM)1208), non-volatile memory (e.g., Read Only Memory (ROM)1210), one or more hard disk drives, one or more solid state drives, one or more compact disk (compact disk) drives, and/or one or more digital versatile disk drives, flash memory 1212, and input/output controller 1214, a digital signal processor (not shown), an encryption processor (not shown), a graphics processor 1216, one or more antennas 1218 (which may be, for example, antennas 208), touch screen displays 1220, touch screen controller 1222, other displays (e.g., liquid crystal displays, cathode ray tube displays, and electronic ink displays (not shown)), a battery 1224 or other power source 1224, Audio codecs (not shown), video codecs (not shown), Global Positioning System (GPS) device 1228, compass 1230, accelerometers (not shown), gyroscopes (not shown), speakers 1232, camera 1234, any other desired sensors (not shown), and so forth. In various embodiments, processor 1204 may be integrated with other components in the same chip to form a system on chip (SoC).

In various embodiments, the volatile memory (e.g., DRAM1208), non-volatile memory (e.g., ROM1210), flash memory 1212, and mass storage device may include program instructions configured to: in response to execution by processor 1204, computing device 1200 is enabled to implement all or selected aspects of the processes described herein (e.g., XML data reception and/or DP message reception, transformation operations, and/or XML data and/or DP message provision). For example, one or more memory components, such as volatile memory (e.g., DRAM1208), non-volatile memory (e.g., ROM1210), flash memory 1212, and mass storage devices may be machine-readable media including temporary and/or persistent (e.g., non-transitory) copies of instructions that, when executed by one or more processors 1204, enable computing device 1200 to implement all or selected aspects of the processes described herein (e.g., the functionality of receive logic 202, conversion logic 204, and/or provide logic 206 of PC 104). Memory accessible by computing device 1200 may include one or more memory resources that are an integral part of the device on which computing device 1200 is installed and/or one or more memory resources that are accessible by computing device 1200 but are not necessarily a part of computing device 1200. For example, the storage resources may be accessed by the computing device 1200 over a network via the communication chip 1206. Any one or more of these memory devices may be included in the memory 208 of the PC 104.

The communication chip 1206 may enable wired and/or wireless communication for data transmission to and from the communication device 1200. The term "wireless" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate signals through the use of modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices do not contain any wires, although in some embodiments the devices may not contain wires. Many of the embodiments described herein may be used with WiFi and the 3GPP/LTE communication systems mentioned above. However, the communication chip 1206 may include any one or more communication chips configured to implement any one of a plurality of wireless standards or protocols to provide any one of a plurality of wireless access technologies. The computing device 1200 may include a plurality of communication chips 1206. For example, a first communication chip 1206 may be designated for short-range wireless communications, such as Wi-Fi and Bluetooth, and a second communication chip 1206 may be designated for long-range wireless communications, such as GPS, EDGE, GPRS, CDMA, WiMAX, LTE, Ev-DO, and so forth.

The following paragraphs describe examples of various embodiments. Example 1 is a PC comprising: receiving logic, receiving XML data transmitted by AF; a conversion logic to convert the XML data into DP messages; and providing logic to provide the DP message for transmission to the PCRF; wherein the XML data includes an AVP element and the AVP element includes an AVP Parameters (AVP-Parameters) element including a first XML element representing an AVP code, a second XML element representing an AVP flag, and a third XML element representing an AVP length.

Example 2 may include the subject matter of example 1, and may further specify that the PC is configured to operate within a Diameter realm including the PCRF.

Example 3 may include the subject matter of example 2, and may further specify that the PC is different from a second PC configured to operate within a second Diameter realm, and that the Diameter realm and the second Diameter realm are within a common 3gpp plmn.

Example 4 may include the subject matter of example 1, and may further specify that the PC is configured to operate within a domain of the AF.

Example 5 may include the subject matter of example 1, and may further specify that the PC is located outside of a domain of the AF and outside of a 3gpp plmn that includes a Diameter realm including the PCRF.

Example 6 may include the subject matter of any of examples 1-5, and may further specify that the XML data includes a plurality of AVP elements, and each AVP element of the plurality of AVP elements includes an AVP parameters element including an XML element representing an AVP code, an XML element representing an AVP flag, and an XML element representing an AVP length.

Example 7 may include the subject matter of any of examples 1-6, and may further specify: according to the XML schema, the AVP parameter element is an element (requiredelete) required by the AVP element.

Example 8 may include the subject matter of example 7, and may further include specifying that the AVP parameters element is included within the AVP element via a reference attribute in the XML schema.

Example 9 is one or more computer-readable media comprising instructions that, when executed by one or more processing devices of a computing device, cause the computing device to perform the steps of: receiving XML data transmitted by the AF; and generating a DP message for transmission to the PCRF based at least in part on the XML data; wherein the XML data includes an AVP element and the AVP element includes an AVP parameters element including a first XML element representing an AVP code, a second XML element representing an AVP flag, and a third XML element representing an AVP length.

Example 10 may include the subject matter of example 9, and may further specify the AVP element as a session id (sessionid) element having a string data type.

Example 11 may include the subject matter of any of examples 9-10, and may further specify the AVP element as a source host (originhome) element, a source realm (OriginRealm) element, a destination realm (DestinationRealm) element, a destination host (destinationhome) element, or a route record (RouteRecord) element, and wherein the AVP element is of a string type.

Example 12 may include the subject matter of any of examples 9-11, and may further specify that the XML data includes a plurality of AVP elements, and each AVP element of the plurality of AVP elements includes an AVP parameters element including an XML element representing an AVP code, an XML element representing an AVP flag, and an XML element representing an AVP length.

Example 13 is a method for protocol conversion, the method comprising: receiving, by a server computing device, a DP message from a PCRF; converting, by the server computing device, the DP message into XML data; and providing, by the server computing device, the XML data for transmission to the AF; wherein the XML data includes an AVP element and the AVP element includes an AVP parameters element including a first XML element representing an AVP code, a second XML element representing an AVP flag, and a third XML element representing an AVP length.

Example 14 may include the subject matter of example 13, and may further specify the AVP element as a media component description element, a subscriber id (subscription id) element, a supported features element, an initiated connection data (sponsored connection availability data) element, or a proxy information (ProxyInfo) element, and wherein the AVP element is of a group (group) type.

Example 15 may include the subject matter of example 14, and may further specify the AVP element as an initiated connection data element, the initiated connection data element including a grant service group (GrantedServiceGroup) element and a user service group (UserServiceGroup) element, and wherein the grant service group element and the user service group element have a group type.

Example 16 may include the subject matter of example 15, and may further specify that each of the authorization service group element and the user service group element comprises a fund group (MoneyGroup) element, and wherein the fund group element is of a group type.

Example 17 may include the subject matter of any of examples 13-16, and may further specify that the server computing device is configured to operate within a Diameter realm including the PCRF.

Example 18 may include the subject matter of any of examples 13-16, and may further specify that the server computing device is configured to operate within a domain of the AF.

Example 19 may include the subject matter of any of examples 13-16, and may further specify that the PC is configured to operate outside of a domain of the AF and outside of a 3gpp plmn including a Diameter realm including the PCRF.

Example 20 is a PC, comprising: receiving logic to receive a DP message from a PCRF; a conversion logic to convert the DP message into XML data; and providing logic to provide the XML data for transmission to the AF; wherein the XML data includes an AVP element and the AVP element includes an AVP parameters element including a first XML element representing an AVP code, a second XML element representing an AVP flag, and a third XML element representing an AVP length.

Example 21 may include the subject matter of example 20, and may further specify that the PC is configured to operate within a Diameter realm including the PCRF.

Example 22 may include the subject matter of example 20, and may further specify: the PC is different from a second PC configured to operate within a second Diameter realm, and the Diameter realm and the second Diameter realm are within a common 3gpp plmn.

Example 23 may include the subject matter of any of examples 20-22, and may further specify that the XML data includes a plurality of AVP elements, each of the plurality of AVP elements including an AVP parameters element, the AVP parameters element including an XML element representing an AVP code, an XML element representing an AVP flag, and an XML element representing an AVP length.

Example 24 may include the subject matter of any of examples 20-23, and may further specify: according to the XML schema, the AVP parameter element is an element required by the AVP element.

Example 25 is a method for protocol conversion, the method comprising: receiving XML data transmitted by the AF; and generating a DP message for transmission to the PCRF based at least in part on the XML data; wherein the XML data includes an AVP element and the AVP element includes an AVP parameters element including a first XML element representing an AVP code, a second XML element representing an AVP flag, and a third XML element representing an AVP length.

Example 26 may include the subject matter of example 25, and may further specify the AVP element as a session ID element having a string data type.

Example 27 may include the subject matter of any of examples 25-26, and may further specify that the AVP element is a source host element, a source realm element, a target host element, or a route record element, and wherein the AVP element is of a string type.

Example 28 may include the subject matter of any of examples 25-27, and may further specify that the XML data includes a plurality of AVP elements, and each AVP element of the plurality of AVP elements includes an AVP parameters element including an XML element representing an AVP code, an XML element representing an AVP flag, and an XML element representing an AVP length.

Example 29 is one or more computer-readable media comprising instructions that, when executed by one or more processing devices of a computing device, cause the computing device to perform the method of any of examples 13-19 and 25-28.

Example 30 is an apparatus comprising means for performing the method of any of examples 13-19 and 25-28.

Claims

1. A Protocol Converter (PC), the protocol converter comprising:

receiving logic to receive extensible markup language (XML) data transmitted by an Application Function (AF);

a translation logic to translate the XML data into a Diameter Protocol (DP) message; and

providing logic to provide the DP message for communication to a Policy and Charging Rules Function (PCRF);

wherein the XML data comprises an attribute-value pair (AVP) element and the AVP element comprises an AVP parameters element comprising a first XML element representing an AVP code, a second XML element representing an AVP flag, and a third XML element representing an AVP length.

2. The PC of claim 1, wherein the PC is configured to operate within a Diameter realm including the PCRF.

3. The PC of claim 2, wherein:

the PC is different from a second PC configured to operate within a second Diameter realm, an

The Diameter realm and the second Diameter realm are within a common third generation partnership project (3GPP) Public Land Mobile Network (PLMN).

4. The PC of claim 1, wherein the PC is configured to operate within a domain of the AF.

5. The PC of claim 1, wherein the PC is located outside of a domain of an AF and outside of a third generation partnership project (3GPP) Public Land Mobile Network (PLMN) that includes a Diameter realm including the PCRF.

6. The PC of claim 1, wherein the XML data includes a plurality of AVP elements, and each AVP element of the plurality of AVP elements includes an AVP parameters element including an XML element representing an AVP code, an XML element representing an AVP flag, and an XML element representing an AVP length.

7. The PC of claim 1, wherein the AVP parameters element is an element required by the AVP element according to an XML schema.

8. The PC of claim 7, wherein the AVP parameters element is included within the AVP element by a reference attribute in the XML schema.

9. One or more computer-readable media comprising instructions, which when executed by one or more processing devices of a computing device, cause the computing device to perform the steps of:

receiving extensible markup language (XML) data transmitted by an Application Function (AF); and

generating, based at least in part on the XML data, a Diameter Protocol (DP) message for communication to a Policy and Charging Rules Function (PCRF);

10. The one or more computer-readable mediums of claim 9, wherein the AVP element is a session ID element having a string data type.

11. The one or more computer-readable media of claim 9, wherein the AVP element is a source host element, a source realm element, a target host element, or a route record element, and wherein the AVP element is of a string type.

12. The one or more computer-readable media of claim 9, wherein the XML data includes a plurality of AVP elements, and each AVP element of the plurality of AVP elements includes an AVP parameters element that includes an XML element representing an AVP code, an XML element representing an AVP flag, and an XML element representing an AVP length.

13. A method for protocol conversion, the method comprising:

receiving, by a server computing device, a Diameter Protocol (DP) message from a Policy and Charging Rules Function (PCRF);

converting, by the server computing device, the DP message into extensible markup language (XML) data; and

providing, by the server computing device, the XML data for transmission to an Application Function (AF);

14. The method of claim 13, wherein the AVP element is a media component description element, a subscriber ID element, a supported features element, an initiated connection data element, or a proxy information element, and wherein the AVP element has a group type.

15. The method of claim 14 wherein the AVP element is an initiated connection data element that includes an authorization service group element and a user service group element, and wherein the authorization service group element and the user service group element have a group type.

16. The method of claim 15, wherein each of the authorized services group element and the user services group element comprises a funds group element, and wherein the funds group element has a group type.

17. The method of claim 13 wherein the server computing device is configured to operate within a Diameter realm including the PCRF.

18. The method of claim 13, wherein the server computing device is configured to operate within a domain of the AF.

19. The method of claim 13 wherein the PC is configured to operate outside of a domain of the AF and outside of a third generation partnership project (3GPP) Public Land Mobile Network (PLMN) that includes a Diameter realm including the PCRF.

20. A Protocol Converter (PC), the protocol converter comprising:

receiving logic to receive Diameter Protocol (DP) thinking from a Policy and Charging Rules Function (PCRF);

a conversion logic to convert the DP message into extensible markup language (XML) data; and

providing logic to provide the XML data for transmission to an Application Function (AF);

21. The PC of claim 20, wherein the PC is configured to operate within a Diameter realm including the PCRF.

22. The PC of claim 20, wherein:

23. The PC of claim 20, wherein the XML data includes a plurality of AVP elements, each AVP element of the plurality of AVP elements including an AVP parameters element including an XML element representing an AVP code, an XML element representing an AVP flag, and an XML element representing an AVP length.

24. The PC of claim 20, wherein the AVP parameters element is an element required by an AVP element according to an XML schema.

25. One or more computer-readable media comprising instructions that, when executed by one or more processing devices of a computing device, cause the computing device to perform the method of any of claims 13-19.