Abstract:
Embodiments of the invention provide an improved major release negotiation mechanism between an initiating node and a receiving node during Diameter session establishment in a 3GPP network.

Description:
FIELD OF THE DISCLOSURE 
     The disclosures made herein relate generally to the telecommunications industry. The invention discussed herein is in the general classification of a device capable of operation in a mode compatible with different versions of the 3GPP standards and a method for operating according to different versions of the 3GPP standards at the PCRF node. 
     BACKGROUND 
     This section introduces aspects that may be helpful in facilitating a better understanding of the invention. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art. Several technical terms and/or phrases will be used throughout this application and merit a brief explanation. The 3rd Generation Partnership Project (3GPP) attempts to create a uniform third-generation mobile phone system. 3GPP standards are called releases and different functionality is present in the different versions of the releases. The 3GPP standards continue to evolve and the major releases of the standards can be differentiated using supported features. It is required that a single release of the Policy and Charging Rules Function (PCRF) be used with different networks operating with different minor versions of the standards. 
     When a new session is established between two 3GPP nodes, e.g.: a PCRF node and a Gxx gateway, the initiating node indicates, in a session request, which 3GPP major release version should be used for the session. The receiving node is either capable of establishing the session under that major release version and replies as such, or if it is not capable, it replies with the next highest major release that under which it can establish the requested session. For example, a Gxx gateway might request a session under 3GPP major release 10 and a PCRF node might reply that it can establish the session under major release 8 or 9. The Gxx gateway would then send a message to the PCRF node indicating that the session should be established under major release 9. Some additional aspects of the prior art are discussed with reference to  FIG. 2  below. 
     Although this exchange between the nodes only takes a few messages, it is highly desirable to have an improved system for negotiating releases during session establishment. for nodes handling a large volume of such messages, and when session establishment delay is undesirable, for example in the case of S9 roaming, it would be advantageous to have a faster and more efficient method of signaling negotiation of the major release on a session request. 
     SUMMARY OF THE DISCLOSURE 
     In embodiments of the invention the initiating node can specify one or more secondary major releases in addition to the preferred major release in a session request message. The receiving node can then determine which release to use and communicate that to the initiating node in a session request answer message. 
     Some embodiments of the invention provide a method of negotiating a release version, performed by a network node. The method comprises steps of: receiving from an initiating node, a session request comprising identification of a plurality of releases supported by the initiating node; determining which of the plurality of releases are also supported by the network node; selecting a preferred release from the also supported releases; transmitting to the initiating node, identification of said selected release. 
     In some embodiments the preferred release comprises the most recent release. 
     In some embodiments the session request comprises a Diameter protocol message. 
     In some embodiments the identification of supported releases is contained in a Supported-Features Attribute Value Pair (AVP). 
     In some embodiments the network node comprises a Policy and Charging Rule Function (PCRF) node. 
     In some embodiments the initiating node comprises a Policy and Charging Enforcement Function (PCEF) gateway node and the message is received on a Gx interface. 
     In some embodiments the initiating node comprises a Bearer Binding and Event Reporting Function (BBREF) gateway node and the message is received on a Gxx interface. 
     In some embodiments the initiating node comprises an Application Function (AF) node and the message is received on an Rx interface. 
     In some embodiments the initiating node comprises a PCRF node and the message is received on an S9 interface. 
     Another aspect of embodiments of the invention provides a method of negotiating a release version, performed by an initiating network node. The method comprises steps of: sending a session request comprising identification of a plurality of releases supported by said initiating node, to a receiving node; receiving from said receiving node, identification of a release selected by said receiving node, also supported by said receiving node from said plurality of releases. 
     Another aspect of embodiments of the invention provides a tangible and non-transitory machine-readable storage medium encoded with instructions for execution by a network node, the tangible and non-transitory machine-readable storage medium comprising: instructions for receiving at the network node, from an initiating node, a session request comprising identification of a plurality of releases supported by the initiating node; instructions for determining which of the plurality of releases are also supported by the network node; instructions for selecting a preferred release from the also supported releases; instructions for transmitting to the initiating node, the selected release. 
     In some embodiments the tangible and non-transitory machine-readable storage medium comprises a Diameter Protocol stack. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Some embodiments of apparatus and/or methods in accordance with embodiments of the present invention are now described, by way of example only, and with reference to the accompanying drawings in which: 
         FIG. 1  illustrates a simplified block diagram of nodes of a 3GPP network; 
         FIG. 2  illustrates a message flow diagram as contemplated by the 3GPP standard; and 
         FIG. 3  illustrates a message flow diagram according to an embodiment of the invention. 
     
    
    
     In the figures, like features are denoted by like reference characters. 
     DETAILED DESCRIPTION 
       FIG. 1  illustrates various elements of a 3rd Generation Partnership Project (3GPP) network  100 . Policy and Charging Rule Function (PCRF) nodes  101 ,  103  can be a Home-PCRF  101  or a Visiting-PCRF  103  and communicate between themselves via the 3GPP-standard-defined S9 interface  105 . PCRF  101  communicates with Application Function (AF) node  107  via the 3GPP-standard-defined Rx interface  109 . PCRF  101  communicates with a Policy and Charging Enforcement Function (PCEF) node  111  via 3GPP-standard-defined Gx interface  113 . PCRF  101  communicates with a Bearer Binding and Event Reporting Function (BBERF) node  115  via 3GPP-standard-defined Gxx interface  117 . The BBERF  115  functionality can be implemented as a part of a Serving Gateway (S-GW)  119 . The S9, Rx, Gx and Gxx interfaces are defined by 3GPP Technical Specifications (TS) 29.215, 29.214, 29.212, and 29.212 standards respectively. 
     Diameter protocol communications sessions are established by sending a session request message to the PCRF  101 . For example, a PCEF would use a Gx Credit Control Request (CCR) message; a BBERF would use a Gxx CCR message; an AF node would use an Rx AA-Request (AAR) message. A PCRF peer would use an S9 CCR message. These session request messages include a Supported-Features Attribute Value Pair (AVP) to inform the receiving node about the required and optional features that the initiating node supports. 
       FIG. 2  illustrates messaging between PCRF node  203  and an initiating Peer Node  201  in a session establishment scenario as contemplated by the 3GPP standards. Peer node  201  can represent a Diameter peer node such as an AF node  107 , a PCEF node  111 , a BBERF node  115  or a peer PCRF  103 . The origination and termination of messages at the initiating peer node  201  and PCRF node  203 , and the respective operations, are depicted along two vertical lines labeled Peer Node and PCRF respectively with time advancing from top to bottom of the figure. Initiating peer node  201  sends a session establishment request message  205  to the PCRF  203  to establish a Diameter session. The message is in accordance with Diameter protocol messaging and as defined by the 3GPP standards for the appropriate interface (Rx, Gx, Gxx, S9). The request message  205  includes a Supported-Features AVP having a Vendor-ID, a Feature-List-ID and a Feature-List. The Feature-List, as defined by the 3GPP standards, includes an indication of a major release of the 3GPP standard under which the session is to be established, the indication taking the form of a binary word having certain bits set in a predefined manner to indicate the major release. In the scenario of  FIG. 2 , Peer Node  201  is running 3GPP major release 10 and PCRF node  203  is running 3GPP major release 9. The Supported-Feature AVP of request message  205  specifies release 10, with the corresponding “M” bit (Mandatory bit) set to “1” to indicate that support of release 10 is required to be able to establish a session based on the request message  205 . Upon receiving the request  205 , at step  207  the PCRF  203  determines if the release 10 indicated in the request message  205  is supported by the PCRF  203 . Since PCRF  203  is running release 9 in this example, PCRF  203  sends a session establishment answer message  209  to Peer Node  201  rejecting the session establishment request message  205  and with the Supported-Features AVP having the feature bits for release 8 and release 9 set and with the corresponding “M” bits cleared, indicating that only release 8 and release 9 are supported by PCRF  203 . At step  210  Peer Node  201  then assesses which major releases are supported by PCRF Node  203 . Since Peer Node  201  supports 3GPP Releases 8, 9 and 10, and PCRF node  203  supports releases 8 and 9, Peer Node  201  selects release 9 as the optimal release for the Diameter session with PCRF Node  203 , and sends a session establishment request message  211  to the PCRF  203  identifying release 9 as mandatory. At step  213  the PCRF  203  determines that release 9 indicated in the request message  211  is supported by the PCRF  203 , and responds with session establishment answer message  215 , accepting release 9 as version of 3GPP standard to use for the session. 
       FIG. 3  illustrates messaging between PCRF node  303  and an initiating Peer Node  301  in a session establishment scenario in accordance with embodiments of the present invention. Initiating peer node  301  sends a session establishment request message  305  to the PCRF  303  to establish a Diameter session. The request message  305  includes a Supported-Features AVP having a Vendor-ID, a Feature-List-ID and a Feature-List. The Feature-List, includes an indication of one or more major releases of the 3GPP standard supported by Peer Node  301  under which the session is to be established. In this example the feature bits representing release 8, 9 and 10 are set and the “M” bit corresponding to the lowest release required—release 8 is set, to indicate that Peer Node  301  supports release 8, 9, and 10 and that release 8 is required as a minimum. 
     Upon receiving session establishment request message  305 , at step  307  the PCRF  303  analyzes message  305  to compare the releases supported by Peer Node  301  with the releases supported by PCRF  303  and selects the highest matching release. In this example, PCRF  303  supports release 8 and 9, thus PCRF  303  selects release 9. PCRF  303  then responds with session establishment answer message  309 , with the Supported-Features AVP having the feature bit for release 9 set and with the corresponding “M” bit cleared, indicating that release 9 has been selected by PCRF  203  and accepting the session establishment request. 
     In this manner, only one round-trip request/response is required to negotiate major releases between a PCRF and an initiating peer node during session establishment. This can have the advantage of saving one or more round-trip request/responses during session establishment for interacting nodes supporting different combinations of releases. Thus for nodes handling a large volume of such messages and for situations where session establishment delay is undesirable, for example in the case of S9 roaming, the described embodiments can be especially valuable, by improving efficiency and performance. 
     Note that the standard session establishment procedure of  FIG. 2  is still supported so that PCRF nodes supporting this embodiment can inter-operate seamlessly with Peer Nodes that do not support this embodiment. 
     The embodiments described above can be implemented as a Diameter Protocol Stack which can be incorporated into a 3GPP network node. 
     The description and drawings merely illustrate the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof. 
     It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Numerous modifications, variations and adaptations may be made to the embodiment of the invention described above without departing from the scope of the invention, which is defined in the claims.