Patent Application
20060168303
The present invention generally relates to Internet Protocol (IP) networks, and more specifically, to coordinating charging for various services involved in providing multimedia sessions.
IP networks were originally designed to carry “best effort” traffic where the network makes a “best attempt” to deliver a user packet, but does not guarantee that a user packet will arrive at the destination. Because of the market success of IP networks, there is a clear requirement for mechanisms that allow IP networks to support various types of applications. Some of these applications have Quality of Service (QoS) requirements other than “best efforts” service. Examples of such applications include various real time applications (IP Telephony, video conferencing), streaming services (audio or video), or high quality data services (browsing with bounded download delays). Recognizing these QoS requirements, the Internet Engineering Task Force (IETF), which is the main standards body for IP networking, standardized a set of protocols and mechanisms that enable IP network operators to build QoS-enabled IP networks.
When users access IP based services, they typically use a device that runs an application program that provides the interface for the user to access the particular service. For instance, in
Various user applications may access network services through an application programming interface (API). An API provides application programmers with a uniform interface to access underlying system resources. For instance, an API may be used to configure a network resource manager to require that a particular IP packet originating from a given application receive a certain treatment from the network, such as a particular QoS. For example, if the IP network is a Differentiated Services IP network, then an application program may request that all of its IP packets receive the “Expedited Forwarding” treatment.
The User (and the API in the user's equipment) may not be aware of the different technologies that various access networks and IP backbone networks employ in order to provide QoS end-to-end, i.e., from User-A all the way to remote User-B. For instance, the user application program may use an RSVP/IntServ based API, and the end-to-end embodiment in which he is involved may include a UMTS access network and a non-RSVP enabled IP network. In such cases, some “interworking” mechanisms between such different technologies and protocols are needed to make sure that the QoS is provided end-to-end.
Integrated Services (IntServ) provides a set of well-defined services which enables an application to choose among multiple, controlled levels of delivery service for their data packets. To support this capability, two things are required. First, individual network elements, such as subnets and IP routers, along the path followed by an application's data packets must support mechanisms to control the quality of service delivered to those packets. Second, a way to communicate the application's requirements to network elements along the path and to convey QoS management information between network elements and the application must be provided.
IntServ defines a number of services such as Controlled-Load (defined in IETF RFC 2211) and Guaranteed (defined in IETF RFC 2212). The service definition defines the required characteristics of the network equipment in order to deliver the service. The individual network elements (subnets and IP routers) that support the service must comply with the definitions defined for the service.
The service definition also defines the information that must be provided across the network in order to establish the service. This function may be provided in a number of ways, but it is frequently implemented by the resource reservation setup protocol (RSVP) (defined in IETF RFC 2205). RSVP (Resource reSerVation Protocol) is an IP-level resource reservation setup protocol designed for an IntServ-enabled Internet (defined in IETF RFC 1633, 2205, and 2210). The RSVP protocol is used by a host (e.g., User A's computer) to request specific service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service requests to all nodes along the path(s) of the flows and to establish and maintain the state(s) to provide the requested service. RSVP requests generally result in resources being reserved in each node along the data path.
A Proxy is a network device, such as a router or a switch, that performs one or more functions on behalf of another device. An RSVP Proxy originates the RSVP RESV message in response to an incoming PATH message on behalf of the receiver(s) identified by the PATH message. (RESV and PATH are well known messages used in RSVP.) In other words, the RSVP (Receiver) Proxy acts on behalf of the remote host and thereby facilitates resource reservation between the originating host and the RSVP Proxy without the host needing to be involved in RSVP signaling. This is shown in
Differentiated Services (DiffServ) enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., “class” differentiation).
Services may be constructed by a combination of setting bits in an IP header field at network boundaries (autonomous system boundaries, internal administrative boundaries, or hosts), using those bits to determine how packets are forwarded by the nodes inside the network, and conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service.
Differentiated Services defines an edge router at the network boundary, and core routers within the network. The edge and core routers have different duties. The edge router must condition the traffic to ensure that it conforms to the service agreement. It also marks the traffic with the appropriate DSCP Differentiated Services Code Point). It then forwards the packet according to the service behavior defined for that DSCP. The service behavior, called the Per Hop Behavior (PHB) may define the prioritization or weighting of that traffic to give it better service than other traffic. The core nodes examine the DSCP and apply the service behavior appropriate for that service.
Services may be constructed by a unique combination of PHB and traffic conditioning. For example, two different services can be created using the same PHB by applying a different traffic conditioning function at the edge routers.
The intServ architecture provides a means for the delivery of end-to-end QoS to applications over heterogeneous networks. To support this end-to-end model, the IntServ architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services may be viewed as a network element in the total end-to-end path.
From the perspective of IntServ, DiffServ regions of the network are treated as virtual links connecting IntServ capable routers or hosts (much as an ethernet LAN can be treated as a virtual link). Within the DiffServ regions of the network, routers implement specific PHBs (aggregate traffic control). The total amount of traffic admitted into the DiffServ region that will receive a certain PHB is controlled by the conditioning at the edge routers. An IntServ service can be provided across a DiffServ domain by applying admission control and traffic conditioning at the edge router to meet the IntServ service specification, and signaling the RSVP service characteristics of the DiffServ domain to the next RSVP enabled router. The information provided in the RSVP signaling should be appropriate for the service across the DiffServ domain. This is shown in
To realize a QoS Service with clearly defined characteristics and functionality, a QoS bearer must be set up from the source to the destination of the service. A bearer is a logical connection between two entities through one or more interfaces, networks, gateways, etc., and usually corresponds to a data stream. A QoS bearer service includes all aspects to enable the provision of a contracted QoS. These aspects are among others the control signaling, user plane transport, and QoS management functionality.
Mobile Radio Access Data Networks, like General Packet Radio Service (GPRS) and Universal Mobile Telecommunication System (UMTS), may form a part of the overall network and will typically be a significant factor in the end-to-end bearer service for customers connected to it. Hence, the bearer service provided over a GPRS/UMTS network must provide the required end-to-end bearer service.
The GPRS/UMTS network includes a set of network elements between the host, referred to as the Mobile Station (MS), and an external packet switching network the user is connecting to like the Internet. These network elements are shown in
Before a mobile host can send packet data to an external host, the mobile host must “attach” to the GPRS network to make its presence known and to create a packet data protocol (PDP) context to establish a relationship with a GGSN towards the external network that the mobile host is accessing. The PDP attach procedure is carried out between the mobile host and the SGSN to establish a logical link. As a result, a temporary logical link identity is assigned to the mobile host. A PDP context is established between the mobile host and a GGSN selected based on the name of the external network to be reached. One or more application flows (sometimes called “routing contexts”) may be established over a single PDP context through negotiations with the GGSN. Again, an application flow corresponds to a stream of data packets distinguishable as being associated with a particular host application. An example application flow is in an electronic mail message from the mobile host to a fixed terminal. Another example application flow is a link to a particular Internet Service Provider (ISP) to download a graphics file from a website. Both of these application flows are associated with the same mobile host and the same PDP context.
User data is transferred transparently between the MS and the external data networks with a method known as encapsulation and tunneling data packets are equipped with PS-specific protocol information and transferred between the MS and the GGSN.
Quality of Service (QoS) has an extremely important and central role in 3rd generation (3G) UMTS mobile networks. QoS is a means for providing end users with satisfying service. QoS also enables efficient use of the spectrum of resources. Because the invention will be described in terms of a UMTS QoS architecture, a brief overview of QoS in UMTS is provided. The 3G UMTS QoS architecture is described, including an explanation of the packet data protocol context (PDP context), a traffic flow template (TFT), and the QoS maintenance procedures for activated UMTS bearers. It is expected that the QoS characteristics associated with a radio communication are the most critical in the end-to-end chain. Within UMTS access networks, the radio network resources are managed on a per PDP context level, which corresponds to one or more user flows/data streams and a certain QoS level.
The QoS framework for 3G networks is specified in the 3G specification (3GPP) TS23.107. The main focus is on the QoS architecture to be used in the UMTS level, where the list of QoS attributes applicable to UMTS Bearer Service and the Radio Access Bearer Service are specified along with appropriate mapping rules. TS23.060 specifies the general mechanisms used by data packet connectivity services in the UMTS level, which includes the General Packet Radio Service (GPRS) in GSM and UMTS.
In a UMTS QoS Architecture, a network service is considered to be end-to-end, from a Terminal Equipment (TE) to another TE. To realize a certain end-to-end QoS, a bearer service with clearly defined characteristics and functionality is set up from the source to the destination of a service. Again, the bearer service includes those aspects needed to enable the provision of a contracted QoS, e.g., control signaling, user plane transport, QoS management and functionality.
A UMTS bearer service layered architecture is depicted in
The following are examples of the entities shown in
The QoS management functions in UMTS are used to establish, modify and maintain a UMTS Bearer Service with a specific QoS, as defined by specific QoS attributes. The QoS management functions of all the UMTS entities ensure provision of the negotiated UMTS bearer service.
The UMTS architecture comprises four management functions in the control plane and four in the user plane. The four control plane management functions are shown in
The four user plane management functions are:
The QoS management functions of the UMTS bearer service in the user plane are shown in
Four different QoS classes standardized in UMTS are shown in
To characterize a bearer service in detail, a set of bearer service attributes are standardized in UMTS as shown in the tables referenced below. A certain QoS is requested by selecting a set of attribute values that describes the bearer requirement. Parameters differ depending on the type of bearer service requested.
A PDP context is implemented as a dynamic table of data entries, comprising all needed information for transferring PDP PDUs between MS and GGSN, for example addressing information, flow control variables, QoS profile, charging information, etc. The relation between UMTS bearer services and PDP context is a one-to-one mapping, i.e., if two UMTS bearer services are established for one PDP address, two PDP contexts are defined. The PDP context procedures are standardized in TS23.060. The concepts surrounding the QoS profile and the Traffic Flow Template (TFT) are relevant from the QoS perspective.
The UMTS QoS attributes have been selected and defined mainly for supporting efficient radio realization. A QoS profile is defined by a set of UMTS QoS attributes. The RNC obtains the pertinent radio access bearer (RAB) QoS profile from the SGSN during PDP context activation. There are three different QoS profiles involved in a PDP context activation—the requested QoS profile, the negotiated QoS profile, and the subscribed QoS profile (or the default QoS profile).
A Traffic Flow Template (TFT) is a packet filter (or set of filters) that associates packets to the correct PDP context thereby ensuring that packets are properly forwarded with correct QoS characteristics. The TFT enables the possibility of having several PDP contexts with varying QoS profiles, associated to a single PDP address. The TFT is managed and initiated by the MT both for the uplink and downlink flows. The uplink TFT resides in the MT, while the downlink TFT resides in the GGSN. The downlink TFT is sent from the MT to the GGSN during PDP context activation/modification. The downlink TFT's may be added to a PDP context that was created without one, and the contents may be modified as well.
The PDP context signaling carries the requested and negotiated QoS profile between the nodes in the UMTS network. It has a central role for QoS handling in terms of admission control, negotiation, and modifying of bearers on a QoS level. The PDP context signaling message exchanges are described below with reference to the numerals in
2. The MS sends a PDP message, “Activate PDP context request,” to the SGSN. The requested QoS profile is included in this message. At this stage, the SGSN makes an admission check and might restrict the requested QoS if the system is overloaded.
3. The SGSN sends a RANAP message, “RAB Assignment Request,” to the RNC in the UTRAN. RANAP, or Radio Access Network Application Part, is an application protocol for supporting signaling and control transmission between the UTRAN and the external CN. RANAP permits communication between the UTRAN and circuit-switched or packet-switched networks. This request to establish a radio access bearer (RAB) service carries the (perhaps modified) RAB QoS attributes.
4. From the RAB QoS attributes, the RNC determines the radio-related parameters corresponding to the QoS profile, e.g., transport format set, transport format combination set, etc. In addition, the UTRAN performs an admission control on this bearer.
5. The RNC sends an RRC message, “Radio Bearer Set-up,” to the MS. The RRC message includes the radio-related parameters that were determined in step 4.
6. The UTRAN and the MS apply the radio parameters and are ready to transfer traffic. To signal this, the MS sends a “Radio Bearer Set-up Complete” RRC message to the RNC.
7. The UTRAN sends a “RAB Assignment Complete” RANAP message to the SGSN.
8. A Trace procedure may be initiated. This is an operation and maintenance function for surveying subscribers.
9. The SGSN sends a “Create PDP Context Request” to the GGSN carrying the QoS profile. However, the QoS profile may have different parameters than those requested by the MS in step 2. Based on this profile, an admission control is performed at the GGSN level, and the GGSN may restrict the QoS if, for example, the system is overloaded. The GGSN stores the PDP context in its databases.
10. The GGSN returns the negotiated QoS to the SGSN in a “Create PDP Context Response” message and the SGSN stores the PDP context in its database.
11. The negotiated QoS is sent from the SGSN to the MS in an “Activate PDP Context Accept” message. If either the SGSN or the GGSN has modified the QoS profile, then the MS has to either accept or reject this profile.
Several admission controls take place in the procedure. Because bandwidth associated with radio is the most expensive resource, the UTRAN is consulted in determining whether radio resources are available during PDP context activation or modification. In other words, admission control in UMTS is performed in a radio centric manner.
To provide IP QoS end-to-end, it is necessary to manage the QoS within each domain. An IP BS Manager in the Gateway is used to control the external IP bearer service. Due to the different techniques used within the IP network, this is communicated to the UMTS BS manager through the Translation function. There is a likewise a need for an IP bearer service manager function to be provided in UE, where the bearer service manager maps the QoS requirements of the application to the appropriate QoS mechanisms.
An IP Multimedia Service (“IMS”) may be defined “on top” of the GPRS bearer service to provide multimedia sessions to end users. The quality of service aspects of bearers supporting IP multimedia is specified in the 3GPP TS 23.207, and the IP multimedia specification is set forth in the 3GPP TS 23.228. The IMS is based on IP application signaling, which in a preferred, example embodiment includes session initiation protocol (SIP) and session description protocol (SDP). SIP is a signaling protocol to establish sessions, and SDP is a text-based syntax to describe the session and includes, for example, the definition of each media stream in the session.
For multimedia sessions, it is important that network managers and services providers be able to monitor, control, and enforce the use of network resources and services based on “policies” derived from certain established criteria such as the identity/authority level of users and applications, traffic bandwidth requirements, security considerations, time of day/week, etc. Because there are varying circumstances in which various entities are entitled to use the services they request, there is a need for rules, a need for enforcement methods of these rules, and a need for a “judge” to decide when they apply. Accordingly, three major components of a policy system include policy rules, which are typically stored in a policy database, policy enforcement, which may be implemented at Policy Enforcement Points (PEP), and Policy Decision Points. The IETF has standardized a protocol for information exchange between PEPs and Policy Decision Points under the term Common Open Policy Service (COPS). In general, a policy may be regarded as a collection of rules that result in one or more actions when specific conditions exist.
Session level policy controls, such as the service-based local policy control described in commonly-assigned U.S. patent application Ser. No. 09/861,817, entitled “Application Influenced Policy,” cannot automatically be applied to PDP contexts unless the relationship of the various media streams to the PDP contexts is known. That is because such relationships are under the control of the end user establishing the multimedia session, the various media streams, and the corresponding quality of service parameters associated with those media streams.
Two of the commonly-assigned applications referenced above, U.S. patent application Ser. No. ______, entitled “Method and Apparatus for Coordinating Quality of Service Requirements for Media Flows in a Multimedia Session With Bearer Resources,” filed on Nov. 5, 2001; and U.S. patent application Ser. No. ______, entitled “Media Binding to Coordinate Quality of Service Requirements for Media Flows in a Multimedia Session With IP Bearer Resources,” filed on Nov. 5, 2001, describe mechanisms for communicating effectively and efficiently the relationship between a session, media flows in that session, and the quality of service required by each media flow in order to request, reserve, supply, and enforce the resources necessary to support each media flow at the IP/PDP bearer level. These mechanisms facilitate interworking and cooperation in end-to-end user sessions where the backbone network uses one protocol, e.g., RSVP, to manage/reserve backbone resources for a session while the mobile terminal/UMTS network uses another protocol, e.g., PDP context information, to interwork with backbone quality of service reservation/management mechanisms.
Multimedia sessions provide operators with opportunities and challenges when it comes to charging for multimedia session services. Certain network operators may want to charge subscribers separately for using the GPRS access network (or a similar access network) using one charging metric, e.g., charge per unit of data, and for session level services using another charging metric, e.g., charge per unit time. However, it is more likely that many may want to issue a single charge for using a multimedia service. One reason is to simplify subscriber bills and accounting. Another reason is to permit network operators to offer a single multimedia session charge which is less than the sum of plural separate charges associated with each separate service employed in a multimedia session.
A further factor to consider is that some operators intending to offer IP multimedia services may want to charge according to established GSM charging principles. This means, among other things, that charges for use of the GPRS access network would be based on time and quality of service. It also means that all of the components involved in the call should be linked together to permit accurate charging considering the time, locations of subscribers, type of service, type of access, etc. It may further include the possibility for an “A-party pays” charging model, where the originating party/side pays for the cost of the entire session just like what is available today in GSM when the terminating B-party is not roaming. For this case, all components involved in the call from both the A-party side and the B-party side should be linked together. Yet another factor is the desirability of linking service-based local policy (SBLP) enforcement, (e.g., as described in U.S. patent application Ser. No. 09/861,817, entitled “Application Influenced Policy,” filed on May 21, 2001), to multimedia session charging.
These and perhaps other factors point to a need for a mechanism to correlate charging information associated with an IP multimedia system which services a multimedia call on a session level and charging information associated with an access bearer network for services provided in the multimedia session on a PDP context/bearer access level to allow operators to take advantage of the information received from both levels to provide flexibility in charging for multimedia sessions.
The present invention provides a mechanism for coordinating charging for a multimedia session between a mobile terminal and a remote host on both an application/session level and on an IP/access bearer level. The multimedia session is established over a radio access network via a packet-switched access network coupled to a multimedia system. The multimedia system has one or more multimedia servers for providing multimedia services for multimedia sessions. A token associated with the multimedia session is generated. Using the token, session charges associated with the multimedia session are correlated for a first operation performed in the packet-switched access network and for a second operation performed by the multimedia system. A first entity in the packet-switched access network includes the session token in a first charging message associated with the session sent to a charging entity. A second entity in the multimedia system includes the session token in a second charging message associated with the session to be sent to the charging entity.
The charging messages may take any number of forms including, for example, first and second call data records (CDRs), first and second charging instances, and different types of charging messages, such as a Customized Applications for Mobile network Enhanced Logic (CAMEL) charging message used in some GSM networks for the first charging message, and a DIAMETER-based charging message used in some IP networks for the second charging message. The first charging message might include, for example, information relating to access bearer services, e.g., location of the mobile terminal, location of the remote host, volume of packets sent or received, quality of service parameters associated with one or more of the packet access bearers employed in the multimedia session, and times. The second charging message may include information related to multimedia services provided at a session level such as type of multimedia service, identity of originating and terminating entities, service-based local policy restrictions, discounted charging scenarios, and amount of time in which session resources are used.
In a non-limiting, example detail, the token may include a session identifier which may, together with a flow identifier generated by the mobile terminal, be used to identify the specific session media flow that will use the packet access network bearer to be correlated to the session. That bearer-specific token may be used to correlate bearer level charges for each media data stream with session level charges for each media data stream.
The token may also be used by the mobile terminal to indicate whether the mobile terminal agrees to a certain charging arrangement for the multimedia session. For example, when the token is issued by the home network operator, the fact of the mobile terminal sending that token to the packet-switched access network may indicate that the mobile terminal agrees to a charging arrangement for the multimedia session where bearer level and session level services for the session are combined or bundled together, rather than charged for separately as they would be if the token was not sent. In addition, sending the token to the packet access network may indicate the mobile terminal's agreement to a service level contract with a home network operator. In either situation, the home network operator issued token is used by the charging entity to correlate or bundle together session level and bearer level services for charging purposes.
The token may be issued by an entity associated with a visited network operator. In this case, the mobile terminal may indicate agreement to service-based local policy (SBLP) enforcement of bearer services in the visited network by sending the token to the packet access network. The packet access network may then send an indication of SBLP enforcement to the charging entity so that the charging entity can take such SBLP into account in charging, e.g., charge at a discounted rate to reward the UE for submitting to SBLP.
In a preferred, non-limiting, example application of the present invention, the mobile terminal is coupled to an IP-based multimedia system (IMS) that provides multimedia services by way of a GPRS network. A service charge identifier corresponding to the session is provided to an IMS entity in the IMS and to a GPRS entity in the GPRS network. Charges relating to services provided in the IMS and in the GPRS network for the session are correlated using the service charging identifier.
The IMS entity may be a call state control function (CSCF) which generates the service charge identifier and sends it to the mobile terminal. If the CSCF is a Serving-CSCF (S-CSCF) associated with the mobile's home network, the mobile terminal can indicate agreement to a service charging arrangement simply by sending the service charging identifier generated by the S-CSCF to the GPRS network. This service charging identifier also allows the charging entity to “bundle” the session level service charges with the PDP context/GPRS bearer level services into one service charge.
The IMS entity generating the service charging identifier may be a Proxy-CSCF (P-CSCF) associated with a network visited by the mobile terminal. As described above, the fact of the mobile terminal sending the service charging identifier to the GPRS network may be used to indicate the mobile's agreement to service-based local policy (SBLP) enforcement of bearer services at the GPRS network level based on policy information for the session provided by the P-CSCF to a gatekeeper node in the GPRS network. The gatekeeper may send an “SBLP-implemented indicator” to the charging entity to indicate that SBLP has been applied in this session. The charging node may take into account that SBLP application in formulating the session charges, e.g., provide a discount to reward the user for agreeing to SBLP in the visited network.
In a preferred example implementation detail, the mobile terminal includes the service charging identifier in a packet data protocol (PDP) context message sent to a node in the GPRS network. The service charging identifier may be included in a PDP configuration options (PCO) field. If the GPRS node is a serving GPRS support node (SGSN), the SGSN may send the service charging identifier with charging information via the GSM-Camel interface for pre-paid services/real-time charging or via a call data record (CDR) for off-line charging to a home network cost control node. The cost control node may perform a variety of charging operations including bundled bearer-service charging, real-time charging, or prepaid charging. A gateway GPRS support node (GGSN) may employ the service charging identifier in a PDP context response message to the SGSN and/or in service based local policy (SBLP) setup, enforcement, and/or charging. The GGSN may send the service charging identifier with charging information via CDR for off-line charging to a home network cost control node.
In another preferred example implementation detail, where a calling party A has a session established with a called party B, a common service charging identifier is passed on to their respective packet-switched access networks and multimedia systems. The common service charging identifier is used by one or more charging nodes to correlate the charges from both A and B sides. This approach facilitates the “A-party pays” charging model, where the originating side party A pays for the cost of the entire session just like what is available today in GSM when the terminating B-party is not roaming. Alternatively, each side uses its own service charging identifier, and the correlation of the two service charging identifiers is carried out via communication between the two charging nodes. Using different service charging identifiers eliminates the need for a global service charging identifier for the session, which is more difficult to handle/standardize.
The foregoing and other objects, features, and advantages of the present invention may be more readily understood with reference to the following description taken in conjunction with the accompanying drawings.
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular embodiments, procedures, techniques, etc. in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. For example, while the present invention is described in an example application to GPRS/UMTS systems, the present invention may be employed in any cellular radio system that offers multimedia services.
In some instances, detailed descriptions of well-known methods, interfaces, devices, and signaling techniques are omitted so as not to obscure the description of the present invention with unnecessary detail. Moreover, individual function blocks are shown in some of the figures. Those skilled in the art will appreciate that the functions may be implemented using individual hardware circuits, using software functioning in conjunction with a suitably programmed digital microprocessor or general purpose computer, using an application specific integrated circuit (ASIC), and/or using one or more digital signal processors (DSPs).
In the following description, a mobile terminal is used as one example of a user equipment (UE) allowing a user access to network services. In a mobile radio communications system, the interface between the user equipment and the network is the radio interface. Thus, although the present invention is described using the term “mobile terminal,” the present invention may be applied to any type or configuration of user equipment that can communicate over a radio interface.
As explained above, to provide IP quality of service end-to-end from mobile terminal to a remote host, it is necessary to manage the quality of service within each domain in the end-to-end path where each domain corresponds to a set of nodes using the same QoS mechanism. An IP bearer service manager may be used to control the external IP bearer service through the external packet data network, e.g., the Internet, to the remote host. However, there must be a way to interwork resources owned or controlled by the UMTS network and resources in the external packet data network. This is particularly important for multimedia-type communications between a mobile terminal and remote host.
Consider the example, simplified communications system shown in
Reference is now made to a Multimedia Charging (block 30) set of procedures shown in flowchart format in
One charging message includes information related to access bearer-level services used for transporting each media stream in the session through the packet-switched access network. That charging information may include a number of different items, non-limiting examples of which include the following: location of the mobile terminal, location of the remote host, volume of packets sent or received, quality of service parameters, and time associated with one or more of the packet access bearers used in the session. Another charging message includes information related to session-level services used for controlling multimedia services requested for the session. That information may include, for example, one or more of the following: type of multimedia service, identity of originating and terminating entities, service-based local policy restrictions, discounted charging scenarios, and an amount of time in which session resources are used.
Methods for generating and using tokens to provide end-to-end IP quality of service, manage that quality of service, support for service-based local policy enforcement on individual multimedia flows in the session, and facilitate interworking of resources owned or controlled by a packet access bearer level network with resources in the external packet data network are described in detail in co-pending, commonly-assigned applications U.S. patent application Ser. No. ______, entitled “Method and Apparatus for Coordinating Quality of Service Requirements for Media Flows in a Multimedia Session With Bearer Resources,” filed on Nov. 5, 2001; and U.S. patent application Ser. No. ______, entitled “Media Binding to Coordinate Quality of Service Requirements for Media Flows in a Multimedia Session With IP Bearer Resources,” filed on Nov. 5, 2001. The present invention describes token-related functions relating to multimedia charging for a multimedia session.
The token may take on any number of forms, some of which convey general information, like a session identifier, or more specific information. Moreover, there may be situations where it is desirable to encrypt the token to ensure that there is no tampering with charges for the multimedia session. As an example of a more general information token, an access network identifier may be included with a session identifier and/or a multimedia system charging identifier for the session may be included with the session identifier. The charging node may use the session identifier and the identifiers associated with the access network and the multimedia system to generate a bundled “session-bearer” charge for the session.
As an example of a more specific information token, media-specific tokens may be employed to permit charging correlation both on a session level and on an individual bearer level. A media-specific token for each media data stream may be generated using a session identifier and a media stream identifier corresponding to that media data stream. The media-specific token is used to correlate individual bearer level charges for each media data stream with session level charges for each media data stream.
In example implementations, the token may be generated by one or more entities in the multimedia system or by the charging entity and sent to the mobile terminal. Moreover, the mobile terminal may send the token to the access network to indicate that the mobile terminal agrees to a particular charging arrangement for the multimedia session. For example, if the mobile terminal sends the token to the charging node via the packet-switched access network, that token may be interpreted by the charging node as an indication that the mobile terminal agrees to combined charging for bearer level and session level services. If the token is not received, then the charging node may charge for bearer level and session level services for the session separately. If the token is issued by an entity associated with the home network operator of the mobile terminal, the mobile may send the token to the packet-switched access network to indicate agreement to a service level contract with the home network operator. When the token is received at the charging node, the charging node takes that fact into account in the session charge. For example, the session charge may be discounted because the user agreed to the service level contract.
In another example embodiment, if the token is issued by an entity associated with a visited network, the mobile may send the token to the PSAN to indicate agreement to service-based local policy (SBLP) enforcement of bearer services at the packet-based access network level in the visited network. Transmission of an SBLP-implemented indication token by a node in the PSAN to the charging node permits the charging node to take that fact into account in the session charge. For example, the session charge may be discounted because the mobile user agreed to SBLP.
The present invention has particularly advantageous example application to multimedia sessions involving a GPRS/UMTS network. Of course, the present invention is not limited to this particular example application or to the example embodiment now described. Reference is made to the communications system shown in
A service charging identifier in accordance with the invention is generated for a session, and it is used by a charging entity to correlate charging-related information for the session. The term service charging identifier (SCI) may encompass more than one type of charging identifier and may be generated by different entities. Typically, the SCI is generated by the S-CSCF, which is the home operator that is providing and coordinating services for the multimedia session requested by UE-A. Alternatively, the service charging identifier may be generated by the proxy-CSCF. If the UE accepts SBLP in the visited network by sending the P-CSCF-generated SCI, the GGSN may send an SBLP implemented indicator to the charging node. Recall also that the UE, the charging node, or other entities may issue an SCI related to the multimedia session.
If the service charging identifier is issued by the S-CSCF during session setup (using for example SIP signaling) to allow coordination of charging at the SIP session level and GPRS bearer level, such a service charging identifier is termed a “Home Operator Charging Identifier” (HOCI) for ease of description. The HOCI is issued by the S-CSCF when the home operator, who owns the multimedia service(s), allows service-bearer bundling of charging for a multimedia session. The HOCI is passed from the S-CSCF 102 via the P-CSCF/Policy Control Function (PCF) 98 to the UE 88 during session setup to permit coordination of charging at both the session level and the bearer level by the charging node 120 when it receives charging related messages including the HOCI. On the other hand, if the HOCI is not issued by the S-CSCF, e.g., the home network operator does not allow service-bearer bundling for service charging, charges are not correlated between the SIP session and the GPRS bearer level. Session charging and bearer charging are carried out independently.
From the perspective of the UE, the HOCI may correspond to certain advantages and/or discounts associated with bundled session-bearer charging. However, to participate in such advantages and/or discounts, the UE may have to agree to bundled charging or to some service level contract with the home operator. More specifically, if the UE sends the HOCI during PDP context activation/modification with the GGSN and the SGSN, this may be interpreted as an agreement to such condition. Upon receipt of the HOCI, the GGSN includes the HOCI in the PDP context activation/modification response message using the PDP configuration options (PCO) parameter. The SGSN may send the HOCI to the charging node 120 before the session for a pre-paid service or in real time via the GSM CAMEL interface (Ge) or off-line using call data records (CDRs) sent by the GSM Ga interface.
The charging node 120 may correspond to a home operator cost control node. As discussed above, receipt of the HOCI from the SGSN for the multimedia session may be interpreted as agreement to one or more charging arrangements including: (1) agreement to bundle charging at the session and GPRS bearer levels, (2) discounts of bearers and/or services with the home and any visited operator depending on roaming/business agreements between the home and visited networks, (3) SBLP charging arrangements, etc. On the other hand, if the HOCI is not received, traditional charging mechanisms such as those employed in current GPRS networks may be applied.
If a HOCI is issued per multimedia session, the UE and the S-CSCF may both generate a media stream-specific HOCI using a predetermined procedure, such as the examples described in the two co-pending U.S. patent applications referenced above. The media stream-specific HOCIs are submitted by the UE to the GGSN during PDP context activation/modification to permit correlation of each specific media stream in the session with its corresponding GPRS bearer. In addition, the PDP configuration options (PCO) parameter in PDP context activation/modification messages may be used to carry a HOCI, a media stream-specific HOCI, or a network-specific HOCI to the GGSN. The network-specific HOCI may be generated by a network node such as the GGSN in the GPRS Network along with the S-CSCF.
The proxy-CSCF may issue the SCI during SIP session setup to allow coordination of charging at a SIP session level and a GPRS bearer level. The P-CSCF issued SCI may be provided to the charging node via the S-CSCF. In addition to certain advantages and discounts associated with bundled session-bearer charging described above for the HOCI, if the service charging identifier is issued by the visited network P-CSCF, it may be used by the UE to indicate whether the UE agrees to be subjected to service-based policy (SBLP) control by the visited network operator. The UE may submit the P-CSCF-issued service charging identifier during PDP context activation/modification. Sending this SCI indicates the UE's agreement to SBLP, and the GGSN performs service-based policy control on the GPRS bearers supporting the session.
The GGSN, upon receipt of the service charging identifier from the UE, includes a “SBLP-implemented” indication or token (different from the SCI) in the PDP context activation/modification response message to the SGSN using, for example, the PDP configuration options parameter. The SGSN may then forward that SBLP-implemented indication in a real time charging message to the charging node 120. Alternatively or in addition, off-line CDRs may be sent to the charging node with the SBLP-implemented indication by the SGSN or the GGSN. The charging node 120 recognizes the SBLP-implemented indication as an agreement by the UE to service-based local policy enforcement of the GPRS bearers by the visited or serving network operator. As a result, the charging node may apply a discounted rate for SBLP-controlled bearers, depending on roaming agreements between home and visited networks, as an incentive to the UE to agree to SBLP.
Charging messages sent from different entities may contain different types of charging information related to the multimedia session. A charging message from the serving-CSCF containing the service charging identifier may relate to the nature of the call (e.g., voice, video, e-mail, etc.) and the duration. A charging message generated by the SGSN or GGSN may relate to the volume of data sent during the call and whether the UE agreed to SBLP in the visited network.
Reference is now made to flowchart routines illustrating example procedures relating to various aspects of the present invention as applied to the example environment illustrated in
Example procedures that may be used for implementing certain aspects of the invention at a GPRS Node (block 150) are now described in the context of a flowchart illustrated in
In one example embodiment, the GPRS node may be the SGSN which sends one or more charging messages to the charging entity 120. Such a charging message could be a CAMEL charging message and may be sent in advance of service use as, for example, in a prepaid service environment, in real time, or off-line. The SGSN includes the SCI in the PDP context request message sent to the GGSN in the GPRS network (block 155). If the GPRS node corresponds to the GGSN, the SCI may be included in a charging message regarding GPRS bearer use for the multimedia session sent to the charging node 120 (block 156). The GGSN includes the SCI in the PDP context response message sent to the SGSN. In addition, if the sending of the SCI by the mobile terminal indicates agreement to service-based local policy, the GGSN may send an SBLP-implemented indicator to the charging node to indicate that SBLP enforcement applies for this session.
Reference is now made to
Reference is now made to the flowchart diagram illustrated in
The side-A charging node 120 may receive information from one or more of the SGSN 94, GGSN 96, the proxy-CSCF/PCF 98, and/or the serving-CSCF 102. The charging node 120 may be coupled to a billing system (not shown) and may be any type of charging entity configured to correlate charges for a multimedia session from multiple sources and levels using a service charging identifier included in each charging message.
The serving-CSCF provides charging node 120 with session level charges related to the multimedia session established between UE-A and UE-B using a service charging identifier (SCI). It is the home network NWA that is responsible for providing the services for the multimedia session initiated by UE-A. Such a charging message from the S-CSCF 102 may be sent, for example, formatted as a DIAMETER message.
In addition, GPRS bearer level services associated with the multimedia session may be provided by the SGSN 94 to the charging node 120 in charging messages that include the service charging identifier. The SGSN 94 may send charging related messages in real time to the charging node 120 as CDRs over the GSM “Ga” interface or as CAMEL based messages over the GSM/CAMEL “Ge” interface. Using the service charging identifier, the charging node 120 correlates the charges for different types of services and at different levels to combine them into a single charge for the multimedia session.
For sessions in which service-based local policy (SBLP) is offered by the visiting network NWC, the P-CSCF 98 may generate an SBLP-related a service charging identifier. The P-CSCF/PCF 98 communicates it to the charging node 120 and to the UE-A. If the UE-A agrees to SBLP in the visited network for the session, e.g., in exchange for a discounted charging rate for the session, it sends the SBLP SCI to the GGSN 96. A message from the GGSN 96 to the charging node 120 includes an SBLP-implemented indicator (different from the SCI) which may be used by the charging node 120 to determine charging for the session. The charging node uses the SBLP-implemented indicator to correlate the SBLP-related charging information with the session. The GGSN 96 may send SBLP charging messages off-line as one or more CDRs.
The network entities for side-B of the session mirror those described for side-A. The home network for UE-B 112 is network NWB which includes a serving-CSCSF 104 and a charging node 122. UE-B 112 is currently coupled to a visiting network NWD via RAN 110. The RAN 110 is coupled to a GPRS network 114 that includes an SGSN 116 coupled to a GGSN 118. Session traffic between UE-A and UE-B travels along the path defined by RAN 90, SGSN 94; GGSN 96, an IP backbone network (not shown), GGSN 118, SGSN 116, and RAN 110. The visited network includes a P-CSCF/PCF 106. The P-CSCF/PCF 106 is coupled to the S-CSCF 104.
The side-B charging node 122 may receive information from one or more of the SGSN 116, GGSN 118, the proxy-CSCF 106, and/or the serving-CSCF 104. The charging node 122 may be coupled to a billing system (not shown) and may be any type of charging entity configured to correlate charges for a multimedia session from multiple sources using a service charging identifier included in each charging message. The two charging nodes 120 and 122 communicate charging information regarding the session using the same service charging identifier. If there is only one charging node for the session, then all of the charging messages for the session from the side A and side B would be communicated to that charging node.
Although the description has focused on the token being sent to the mobile terminal, in another example embodiment where a calling party A has a session connected to a called party B, a common service charging identifier (token) is passed on to the packet-switched access networks and multimedia systems of both A side and B side. The common service charging identifier is used by a charging node of both sides to correlate the charges from both A and B sides. The common SCI facilitates the “A-party pays” charging model, where the originating side party A pays for the cost of the entire session just like what is available today in GSM when the terminating B-party is not roaming. Alternatively, both sides can use different/independent service charging identifiers, and the correlation of the two service charging identifiers is carried out via communication between the two charging nodes. This way the service charging identifier need not be “global” in nature which is more difficult to handle/standardize.
Furthermore, both side A and side B may use different/independent service charging identifiers, and the correlation of the two service charging identifiers is carried out via communication between the two charging nodes. This approach eliminates the need for a global SCI identifier, which might be more difficult to handle/standardize than a different SCI per side. Each side's SCI should be unique per session for one user. One way to construct these different SCIs is to combine a session identifier with UE-A identifier, (e.g., UE-A's IMSI), and the same session identifier with UE-B's identifier. As described above, the UE may add a flow identifier to differentiate between the media flows in the session. Each side's SCI may preferrably be “encrypted” (not predictable) to ensure that there is no tampering with the SCIs in an effort to avoid session charges or obtain cheaper session charges.
While the present invention has been described with respect to particular embodiments, those skilled in the art will recognize that the present invention is not limited to these specific exemplary embodiments. Different formats, embodiments, and adaptations besides those shown and described as well as many variations, modifications, and equivalent arrangements may also be used to implement the invention. Therefore, while the present invention has been described in relation to its preferred embodiments, it is to be understood that this disclosure is only illustrative and exemplary of the present invention. Accordingly, it is intended that the invention be limited only by the scope of the claims appended hereto.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0115340.2 | Jun 2001 | GB | national |
This application is related to commonly-assigned U.S. patent application Ser. No. 09/768,956, entitled “RSVP Handling in 3G Networks,” filed on Jan. 24, 2001; U.S. patent application Ser. No. 09/861,817, entitled “Application Influenced Policy,” filed on May 21, 2001, U.S. patent application Ser. No. ______, entitled “Method and Apparatus for Coordinating Quality of Service Requirements for Media Flows in a Multimedia Session With Bearer Resources,” filed on Nov. 5, 2001; and U.S. patent application Ser. No. ______, entitled “Media Binding to Coordinate Quality of Service Requirements for Media Flows in a Multimedia Session With IP Bearer Resources,” filed on Nov. 5, 2001, the disclosures of which are incorporated herein by reference. This application claims priority from and incorporates by reference the following commonly-assigned provisional patent applications: 60/275,354 entitled “Enhancement of Authorization Token for RSVP Interworking,” filed Mar. 13, 2001; 60/273,678 entitled “SDP Support for QoS Based SIP Sessions,” filed Mar. 6, 2001; 60/269,573 entitled “QoS Characteristics for a UMTS Bearer Appropriate for IP Signaling,” filed Feb. 16, 2001; 60/269,789 entitled “Architecture for Packet Data Protocol Context Suitable for Signaling,” filed Feb. 16, 2001; 60/269,572 entitled “Binding a Signaling Bearer for Use With an IP Multimedia Subsystem,” filed Feb. 16, 2001; 60/267,737 entitled “Authorization Token in PDP Context Activation/Modification in Bearer Establishment for SIP Call Setup (Qos),” filed Feb. 9, 2001; 60/260,766 entitled “QoS Pre-Condition Met,” filed Jan. 10, 2001; 60/260,765 entitled “IP Specific Elements in PDP Context Activation/Modification,” filed Jan. 10, 2001; 60/246,501 entitled “Principle of User Choice,” filed Nov. 6, 2000; 60/248,110 entitled “Triggering RSVP Host,” filed Nov. 13, 2000; 60/324,523, entitled “Use of GPRS APN in IMS/IPv6 Context,” filed on Sep. 26, 2001; 60/330,501, entitled “Method an Apparatus for Coordinating Charging for Services Provided in a Multimedia Session,” filed Oct. 23, 2001; and a Great Britain provisionally filed application GB prov 0115340.2, entitled “Real Time GPRS Charging for IP Multimedia,” filed on Jun. 22, 2001.
| Number | Date | Country | |
|---|---|---|---|
| 60275354 | Mar 2001 | US | |
| 60273678 | Mar 2001 | US | |
| 60269573 | Feb 2001 | US | |
| 60269789 | Feb 2001 | US | |
| 60269572 | Feb 2001 | US | |
| 60267737 | Feb 2001 | US | |
| 60260766 | Jan 2001 | US | |
| 60260765 | Jan 2001 | US | |
| 60246501 | Nov 2000 | US | |
| 60248110 | Nov 2000 | US | |
| 60324523 | Sep 2001 | US | |
| 60330501 | Oct 2001 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09985633 | Nov 2001 | US |
| Child | 11386768 | Mar 2006 | US |
