U.S. patent application number 10/924898 was filed with the patent office on 2005-10-27 for charging in communication networks.
This patent application is currently assigned to Nokia Corporation. Invention is credited to Ekman, Jani, Rantala, Pertti, Stura, Marco.
Application Number | 20050240520 10/924898 |
Document ID | / |
Family ID | 32344219 |
Filed Date | 2005-10-27 |
United States Patent
Application |
20050240520 |
Kind Code |
A1 |
Stura, Marco ; et
al. |
October 27, 2005 |
Charging in communication networks
Abstract
A method of communication includes the step of requesting at
least one service having a plurality of parts. The method also
includes determining if the at least one service is providable by
taking into account credit information relating to a user. If not,
the method also includes providing only one or some of the
plurality of parts of the at least one service.
Inventors: |
Stura, Marco; (Espoo,
FI) ; Ekman, Jani; (Kangasala, FI) ; Rantala,
Pertti; (Espoo, FI) |
Correspondence
Address: |
SQUIRE, SANDERS & DEMPSEY L.L.P.
14TH FLOOR
8000 TOWERS CRESCENT
TYSONS CORNER
VA
22182
US
|
Assignee: |
Nokia Corporation
|
Family ID: |
32344219 |
Appl. No.: |
10/924898 |
Filed: |
August 25, 2004 |
Current U.S.
Class: |
705/39 |
Current CPC
Class: |
H04M 17/00 20130101;
H04L 12/1467 20130101; H04M 2215/8166 20130101; H04W 4/24 20130101;
H04M 2215/208 20130101; G06Q 20/10 20130101; H04M 15/8292 20130101;
H04M 15/854 20130101; H04M 15/8271 20130101; H04L 12/14 20130101;
H04L 51/00 20130101; H04L 65/1006 20130101; H04M 15/63 20130101;
H04M 15/57 20130101; H04L 65/1016 20130101; H04M 2215/204
20130101 |
Class at
Publication: |
705/039 |
International
Class: |
G06F 017/60 |
Foreign Application Data
Date |
Code |
Application Number |
Apr 22, 2004 |
GB |
0408990.0 |
Claims
1-19. (canceled)
20. A method of communication, the method comprising the steps of:
requesting at least one service having a plurality of parts;
determining if said at least one service is providable by taking
into account credit information relating to a user; and if not,
providing at least one of said plurality of parts of said at least
one service.
21. A method as claimed in claim 20, wherein said requesting step
includes at least one of said plurality of parts comprising at
least two different services or at least two components of a
service.
22. A method as claimed in claim 21, wherein said at least two of
said components of the service comprise audio and video
components.
23. A method as claimed in claim 20, wherein said determining step
includes determining said credit information is that of said user
requesting the at least one service.
24. A method as claimed in claim 20, wherein said determining step
includes determining said credit information is that of another
user being called by the user requesting the at least one
service.
25. A method as claimed in claim 20, wherein said determining step
includes determining said credit information comprising an amount
of money prepaid by the user.
26. A method as claimed in claim 20, wherein said determining step
is comprises taking into account a cost for each of said plurality
of parts.
27. A method as claimed in claim 26, comprising dropping at least
one part of said plurality of parts which is most expensive and not
providing the at least one part of said plurality of parts in said
providing step.
28. A method as claimed in claim 20, wherein said determining step
is comprises determining which of said plurality of parts is to be
dropped.
29. A method as claimed in claim 28, wherein said determining step
comprises determining which of said plurality of parts is to be
dropped based on a predetermined policy.
30. A method as claimed in claim 29, comprising taking into account
at least one of said credit information and user equipment
capability in said predetermined policy.
31. A method as claimed in claim 28, wherein said determining step
comprises determining which of said plurality of parts is to be
dropped based on a predetermined policy, wherein said predetermined
policy is specific to the user.
32. A method as claimed in claim 28, comprising defining said
predetermined policy by an operator of a communications network
associated with said user.
33. A method as claimed in claim 20, wherein said determining step
comprises taking place in at least one of user equipment, a
charging node, and a node intermediate said user equipment and said
charging node.
34. A method as claimed in claim 33, comprising the step of storing
at a least part of said predetermined policy in the at least one of
said user equipment, said intermediate node and said charging
node.
35. A method as claimed in claim 34, comprising defining said
predetermined policy in said charging node.
36. A method as claimed in claim 35, comprising storing part of
said predetermined policy in at least one of the user equipment and
said intermediate node, said part of said predetermined policy
selected based on the credit information.
37. A method as claimed in claim 34, further comprising the step of
modifying the at least part of said predetermined policy stored in
said at least one of said user equipment and said intermediate node
if said credit information changes.
38. A communication system comprising: user equipment to request at
least one service having a plurality of parts; means for
determining if said at least one service is providable taking into
account credit information relating to a user; and means for
providing at least one of said plurality of parts of said at least
one service if not providable.
39. A communication system as claimed in claim 38, wherein said
determining means are provided in at least one of a charging node,
said user equipment and an intermediate node between said user
equipment and said charging node.
40. A charging node for use in a communications system, said
charging node configured: to receive information for a user
indicating at least one service requested, said at least one
service having a plurality of parts, to check for said user
associated credit information to determine if all of the requested
at least one service is providable, and if not, to determine which
of said plurality of parts is to be dropped.
41. A charging node as claimed in claim 40, wherein said charging
node is provides at least one of information indicating which of
said parts of said plurality of at least one service is to be
provided and a granted monetary unit.
42. A charging node for use in a communications system, said
charging node determines information for a user indicating which at
least one service or components of the at least one service are
providable together, taking into account user associated credit
information and to provide said credit information to another
node.
43. User equipment for use in a communication system, said user
equipment determines if at least one service having a plurality of
parts is providable, taking into account credit information
associated with a user of said user equipment, and, if not, to
request at least one of said plurality of parts.
44. A charging node in a communication system, said charging node
comprising: receiving means to receive information for a user
indicating at least one service requested, said at least one
service having a plurality of parts; checking means to check for
said user associated credit information to determine if all of the
requested at least one service is providable; and determining means
to determine which of said plurality of parts is to be dropped if
all of the requested at least one service is not providable.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to charging in communication
networks, and in particular but not exclusively in third generation
(Universal mobile telecommunication system UMTS) networks.
BACKGROUND OF THE INVENTION
[0002] A communication system is a facility that enables
communication between two or more entities such as user terminal
equipment and/or network entities and other nodes associated with a
communication system. The communication may comprise, for example,
communication of voice, electronic mail (email), text messages,
data, multimedia and so on.
[0003] The communication may be provided by a fixed line and/or
wireless communication interfaces. A feature of wireless
communication systems is that they provide mobility for the users
thereof. An example of communication systems providing wireless
communication is a public land mobile network (PLMN). An example of
the fixed line system is a public switched telephone network
(PSTN).
[0004] A communication system typically operates in accordance with
a given standard or specification which sets out what the various
elements of a system are permitted to do and how that should be
achieved. For example, the standard or specification may define if
the user, or more precisely user equipment, is provided with a
circuit switched server or a packet switched server or both.
Communication protocols and/or parameters which should be used for
the connection are also typically defined. For example, the manner
how communication shall be implemented between the user equipment
and the elements of the communication networks is typically based
on a predefined communication protocol. In other words, a specific
set of "rules" on which the communication can be based needs to be
defined to enable the user equipment to communicate via the
communication system.
[0005] The introduction of Third Generation (3G) communication
systems will significantly increase the possibilities for accessing
services on the Internet via mobile user equipment (UE) as well as
other types of UE.
[0006] Various user equipment (UE) such as computers (fixed or
portable), mobile telephones, personal data assistants or
organisers and so on are known to the skilled person and can be
used to access the Internet to obtain services. Mobile user
equipment referred to as a mobile station (MS) can be defined as a
means that is capable of communication via a wireless interface
with another device such as a base station of a mobile
telecommunication network or any other station.
[0007] The term "service" used above and hereinafter will be
understood to broadly cover any service or goods which a user may
desire, require or be provided with. The term also will be
understood to cover the provision of complimentary services. In
particular, but not exclusively, the term "service" will be
understood to include Internet protocol multimedia IM services,
conferencing, telephony, gaming, rich call, presence, e-commerce
and messaging e.g. instant messaging. A "service" may comprise two
or more parts. For example, a video telephone service comprises a
voice part and a video part. Alternatively two or more services may
be provided at the same time, for example a gaming service and a
chatroom service may be provided at the same time.
[0008] The 3G Partnership Project (3GPP) is defining a reference
architecture for the Universal Mobile Telecommunication System
(UMTS) core network which will provide the users of user equipment
UE with access to these services. This UMTS core network is divided
into three principal domains. These are the Circuit Switched
domain, the Packet Switched domain and the Internet Protocol
Multimedia (IM) domain.
[0009] The latter of these, the IM domain, makes sure that
multimedia services are adequately managed. The IM domain supports
the Session Initiation Protocol (SIP) as developed by the Internet
Engineering Task Force (IETF).
[0010] In prepaid schemes, when a service or services are being
requested, the S-CSCF/SCF (serving call session control
function/session charging functions) requests a quota (allocation
of money which has been prepaid) from the Online Charging System
(OCS). The S-CSCF/SCF sends all the service information required to
rate the service. In the case of a SIP session, all the SDP
(Session Description Protocol) information such as media type,
media codec etc. are sent to the OCS. If the account cannot cover
the cost of the service or services requested, the OCS instructs
the S-CSCF/SCF to release the ongoing session. However, the account
may have sufficient fund in it to pay for a subset of the requested
medias, for instance if a video call (voice and video) is requested
the account may cover the cost for the voice component only.
Nevertheless, with the current proposals the session will be
released.
SUMMARY OF THE INVENTION
[0011] It is an aim of embodiments of the present invention to
address the problems discussed previously
[0012] According to a first embodiment of the present invention,
there is provided a method of communication comprising the steps
of: requesting at least one service having a plurality of parts;
determining if said at least one service can be provided taking
into account credit information relating to a user; and if not
providing only one or some of said plurality of parts of said at
least one service.
[0013] According to another embodiment of the present invention
there is provided a communication system comprising: user equipment
arranged to request at least one service having a plurality of
parts; means for determining if said at least one service can be
provided taking into account credit information relating to a user;
and means for providing, if not, only one or some of said plurality
of parts of said at least one service.
[0014] According to another embodiment of the present invention,
there is provided a charging node for use in a communications
system, said node being arranged to receive information for a user
indicating the at least one service requested, said at least one
service having a plurality of parts, to check for said user
associated credit information to determine if all of the requested
at least one service can be provided, and if not to determine which
of said plurality of parts is to be dropped.
[0015] According to another embodiment of the present invention
there is provided a charging node for use in a communications
system, said node being arranged to determine information for a
user indicating which at least one service and/or components of at
least one service can be provided together, taking in to account
user associated credit information and to provide said information
to another node.
[0016] According to another embodiment of the present invention,
there is provided a user equipment for use in a communication
system, said user equipment being arranged to determine if at least
one service having a plurality of parts can be provided, taking
into account credit information associated with a user of said user
equipment, and if not to request only one or some of said plurality
of parts.
BRIEF DESCRIPTION OF DRAWINGS
[0017] For a better understanding of the present invention and as
to how the same may be carried into effect, reference will now be
made to the accompanying drawings in which:
[0018] FIG. 1 shows a schematic system in which embodiments of the
present invention can be implemented;
[0019] FIG. 2 shows the signal flow in a first embodiment of the
invention;
[0020] FIG. 3 shows the signal flow in a second embodiment of the
invention;
[0021] FIG. 4 shows the signal flow in the second embodiment of the
invention when a user's account is replenished; and
[0022] FIG. 5 shows the signal flow where a party different to that
initiating a session is to pay.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
[0023] In this document, SIP messages are indicated in
capitals.
[0024] Reference is made to FIG. 1 which shows schematically a
system in which embodiments of the invention can be implemented.
The system comprises user equipment 2. The user equipment 2 can
take any suitable form and may for example be a mobile or fixed
entity such as a mobile telephone, personal digital assistant
(PDA), portable computer, laptop computer, fixed computer or any
other suitable device. The user equipment 2 is arranged to
communication with a radio access network (RAN) 8 via a wireless
connection. This wireless connection may be at any suitable
frequency, such as for example a radio frequency.
[0025] The radio access network 8 generally consists of a base
station entity (sometimes referred to as node B). For the purpose
of this document, the term base station will be used and is
intended to cover any suitable entity. The radio access network 8
also comprises a control element. Depending on the standard, the
control element can be referred to as a radio network controller
(RNC) in the case of a UMTS system or a base station controller
(BSC) in the case of a GSM system. It is intended that the term
controller cover any such control entity. In some arrangements, the
control function is provided separately from the base station
function and a single control entity may control a number of base
stations. In other embodiments of the present invention, each base
station may incorporate part of the control function.
[0026] The radio access network is arranged to communicate with a
core network 10. The core network 10 illustrated in FIG. 1 is a
packet switched core network. The core network comprises at least
one serving GPRS (general packet radio service) support node SGSN
which is used to switch the packet switched transactions and at
least one GPRS support nodes GGSN which are switches at the point
where the core network 10 is connected to external packet switched
networks.
[0027] The core network is connected to an IM (IP multi-media)
subsystem 14. A GGSN is connected to a P-CSCF 16 (proxy call
session control function) in the IMS 14. The P-CSCF is connected to
a serving S-CSCF 24. The S-CSCF contacts an interrogating I-CSCF 22
in the terminated network. The I-CSCF 22 is arranged to determine
the appropriate serving-CSCF (S) 24 for the end user, that is the
called party.
[0028] It should be appreciated that in practice, there will be
more that one P-CSCF, I-CSCF and S-CSCF.
[0029] The IMS 14 is connected to an Online charging system 6 which
may be positioned in any location in the system.
[0030] FIG. 1 shows a calling party. The called party may be
connected to a different or the same IMS. Likewise, the called
party may be connected to the same or a different OCS. Where the
called party is connected to a different IMS, a different core
network and RAN are provided. Where the IMS is the same, different
core networks may or may not be required. Likewise, the RAN may be
the same or different for the called party to that of the calling
party.
[0031] Reference is made to FIG. 2 which shows the signal flow in a
first embodiment of the present invention. In particular, FIG. 2
shows the signal flow between the user equipment 2, the S-CFCF/SCF
4, and the OCS 6.
[0032] In step S1 the user equipment 2 sends an INVITE message to
the S-CSCF/SCF 4. This INVITE message will indicate what service or
services the user equipment is requesting. For example, the INVITE
message may indicate that the user is requesting a video call with
a video component and voice component.
[0033] In step S2, the S-CSCF/SCF 4 checks the session data
protocol SDP message against local media policy. In other words,
the description of the user is checked to see whether or not a user
is entitled to obtain the particular service or services. It is
also checked to see whether or not the user is a prepaid user or
not.
[0034] If the user is a prepaid user, then in step S3, a DIAMETER
credit control message (CCR CREDIT CONTROL REQUEST) is sent from
the S-CSCF/SCF. This will include the information included in the
original INVITE message of step 1 indicating the requested media
components of the service or services. This is to find out if the
user has sufficient funds in his account for the requested service
or services. This is a quota reservation request and includes all
the media types and codecs. The DIAMETER CREDIT-CONTROL-REQUEST
(INTIAL REQUEST) with SDP-Session-Description and
SDP-Media-Component AVPs (attribute value pairs) is sent. In the
request there will be as many SDP-Media-Component AVPs as media
components requested by the UE.
[0035] In step S4, the OCS 6 looks at how much money the user has
left in his account. The OCS 6 also has a predefined policy which
in this embodiment of the present invention is applied to all for
example prepaid users. In other embodiments of the invention
different policies may be applied to different users. The policy
indicates that if the amount of money in the account is less than a
certain amount then the user will be denied certain services. Where
the user has requested two or more services and/or a service having
two or more components, then a decision will be made in the OCS,
depending on the amount of money left in the account, as to whether
or not the user is permitted to receive all of the services and/or
service components. If it is determined that there is not
sufficient money in the account to support all of the services
and/or service components, a decision is made to determine which of
the services and/or service components is to be dropped. For
example, in the case of a video call, if the user does not have a
certain amount of money in his account, then the user would only be
permitted to have the voice part of the call. Another example would
be where a user has requested a game session along with an
associated chat session. The user may be able to receive only one
of these services. In the case of a film having an audio and a
visual part, a decision may be made that if the user cannot have
both components, then he will receive neither component. The policy
contained in the OCS 6 would define which of those services would
have priority. The actual policies defined and applied to the user
will be controlled by the operator. Thus, in step S4, the OCS
determines how much money the user has left in his account and will
consider that in relation to the requested services. It should be
appreciated that different services may have different thresholds.
The OCS will then make a decision to which, if any of the services
the user is able to receive. Thus the OCS performs credit
reservation and rates the service request. It determines if any of
the components or services need to be dropped in order to permit
the connection to go ahead and if so which one of the components or
services is to be dropped. This step may be repeated through out
the duration of a connection.
[0036] In step S5, the OCS 6 will send a CCA CREDIT CONTROL ANSWER
message back to the S-CSCF/SCF 4 which will provide information as
to which media components and/or services requested are permitted
and also a granted unit of money for the granted service and/or
service components. An AVP indicates the allowed medias e.g.
Allowed-Media-Components AVP of type grouped, that is built up of 1
to n SDP-Media-Component AVPs (defined in the third generation
partnership specification TS 32.225).
[0037] In step S6, the S-CSCF/SCF 4 will send a session data
protocol reply to the user equipment indicating which of the
services or media components requested are permitted. The message
can take any suitable form and may indicate the services and/or
components allowed and/or may indicate the services and/or
components which are not allowed.
[0038] In step S7, the S-CSCF/SCF 4 will store the OCS 6 determined
media policy, that is which of the media components or services
have been allowed and also the granted units as received from
OCS.
[0039] In step S8, the user equipment will send another INVITE
message which again is a session data protocol message which will
now include a request for only those services which are permitted.
This will in preferred embodiments of the present invention be done
automatically by the user equipment or the application associated
with the user equipment, without the intervention of the user.
There is no need to a second request to the OCS for an allocated
unit of money since this has already been done.
[0040] In alternative embodiments of the invention, the user may be
advised as to which of the components and/or services are permitted
and he will generate a new request based on the allowed services or
may alternatively request a different service components and/or
services. This latter modification would require checking against
the OCS media policy again.
[0041] In step S9, the session data protocol message received in
step S8 is checked by the S-CSCF/SCF 4 against the stored media
policy. If the requested services are in agreement with the policy,
this information being stored in S7, then the INVITE request is
sent in step S10 to the I-CSCF in the terminated network. The user
is then able to receive the requested media component or
services.
[0042] Reference is made to FIG. 3 which shows an alternative
embodiment of the present invention. Again, this figure shows the
signal flow between user equipment, the S-CSCF/SCF and the OCS.
[0043] In step T1, a REGISTER message is sent from the user
equipment to the S-CSCF/SCF 4. This is effectively sent for example
when the user equipment is switched on.
[0044] In step T2, the S-CSCF/SCF 4 will download subscription
information from the HSS (home subscriber service), a database
storing subscription information about the user.
[0045] In step T3, the S-CSCF/SCF 4 will send a CCR request to the
OCS 6. This will request a credit check, service parameter
information or media. The S-CSCF sends a CREDIT-CONTROL-REQUEST
(Event_Request) with Requested-Action AVP set to the value
CHECK_BALANCE. For instance, the Service-Parameter-Info AVP
specifies that media policy is requested, alternatively a new AVP
may be defined to request media policy (for instance
Media-Policy-Request AVP of type Enumerated. 0 would mean
NOT_REQUESTED, 1 would mean REQUESTED. If present in a check
balance request it must be always set to REQUESTED).
[0046] In step T4, the OCS 6 will check the user's credit balance
and determine the media policy. The policy stored in the OCS 6 can
be the same as described in relation to the first embodiment.
[0047] If there is enough balance, the OCS will not return any
media policy restriction and the Check-Balance-Result AVP will be
set to ENOUGH_CREDIT. Otherwise the OCS will return the
Allowed-Media-Components AVP, that contain the media policy
restrictions, and the Check-Balance-Result AVP will be set to
NO_CREDIT. Thus in step T5, the OCS 6 sends the message to the
S-CSCF/SCF 4 indicating that there is not enough credit for
unlimited use of all of the services by the user equipment and an
indication as to the allowed media component(s) and/or service(s)
available to the user. This thus takes into account the amount of
money that the user has in his account.
[0048] In step T6, the S-CSCF/SCF 4 stores the OCS determined media
policy for the particular user.
[0049] In step T7, the S-CSCF/SCF 4 sends a 200 OK message, a
NOTIFY request or any other suitable message to the user equipment
which includes information about the policy. For example, this may
include an indication as to which service(s) and/or media
component(s) are available to the user equipment, information as to
those component(s) and/or service(s) that are unavailable to the
user, and/or policy information which allows the terminal to make
decisions as to whether or not the user is allowed to obtain the
requested service(s) and/or the media component(s).
[0050] In step T8, the user equipment 2 stores the determined media
policy received from the S-CSCF/SCF.
[0051] In step T9, the user equipment 2 will send an INVITE message
indicating the media component(s) and/or service(s) required by the
user. However, the user will only request those component(s) and/or
services allowed by the media policy. In other words, the user will
not request any component or combination of components and/or
services which would not be permitted given the current state of
the user's account.
[0052] The next step T10 involves the S-CSCF/SCF sending a CCR
message, such as shown in step S3 to be OCS 6. Step T11 is the same
as S5 shown in FIG. 1 and is sent from the OCS 6 to the
S-CSCF/SCF.
[0053] The embodiment shown in FIG. 3 differs from that shown in
FIG. 2 in that the allowed media component or components (i.e. the
policy) is known in the user equipment prior to initiating the
session whereas in the embodiment shown in FIG. 1 the decision is
made in the OCS 6 during session establishment. It should be
appreciated that in the embodiment shown in FIG. 3, a check may be
made between steps T10 and T11 to determine that the user still has
enough funds for the requested media component(s) and/or
service(s).
[0054] Reference is made to FIG. 4 which is used in conjunction
with the embodiment shown in FIG. 3 and shows the situation where
the user replenishes his account after registering. In step A1, the
user replenishes his account i.e. increases the amount of funds
available for a connection.
[0055] In step A2, the user sends a message such as an INVITE
message to the S-CSCF/SCF 4.
[0056] In step A3, the S-CSCF/SCF will check if the user is a
prepaid user. If so the next step is A4 in which the S-CSCF/SCF
sends a CCR message to the OCS 6. This is the same as the message
sent in step T3. If the S-CSCF sent a media policy restriction
received from the OCS, it shall trigger a CREDIT-CONTROL-REQUEST
(Event-Request) with Requested-Action AVP set to the value
CHECK_BALANCE upon any event generated by the user (e.g. INVITE,
MESSAGE, SUBSCRIBE etc.) to check if the media policy restriction
is still applicable since the user may have replenished his/her
account.
[0057] In step A5, the OCS provides a message, a CCA message which
indicates that there is enough credit. This message may
alternatively or additionally indicate that there is sufficient
credit with any limitations or indicate if the determined media
policy needs to be changed. If the media policy needs to be
changed, the new media policy for the user given the new state of
his account may be provided by the OCS. If the restriction is not
applicable anymore, the S-CSCF will receive an answer with
"ENOUGH_CREDIT" (and without Allowed-Media-Components AVP) from the
OCS and the terminal will be notified of the new condition.
[0058] In step A6, the OCS determined media policy is removed from
the S-CSCF/SCF's store or modified in dependence on the information
received from the OCS. The S-CSCF/SCF sends a message in step A7 to
the user equipment. This message is a NOTIFY message which provides
information that the old determined media policy is to be removed
or modified. In step A8, the user equipment will remove the old
media policy. If there is a new media policy, that would be stored.
In step A9, the user equipment 2 sends an acknowledgement message
which may for example be a 200 OK message to the S-CSCF/SCF 4.
[0059] It should be appreciated that step A4 and A5 may be included
in the embodiment shown in FIG. 3 between steps T9 and T10.
[0060] Reference will now be made to FIG. 5 which shows a further
modification to embodiments of the present invention. In the
embodiment shown in FIG. 5, the session is being paid by the
terminating user equipment. This can be used in conjunction with
either the embodiment shown in FIG. 2 (embodiment 1) or the
embodiment shown in FIG. 3 (embodiment 2). The example shown in
FIG. 5 is described in relation to the first embodiment. If the
calling party requests to the called party to take the charges for
the call, the terminating S-CSCF may use two different approaches
to check with the OCS if media policy limitation is applicable:
[0061] 1--since the network cannot know if the called party will
accept the charges, the terminating S-CSCF can consult the OCS
without requesting money reservation (i.e.
Credit-Control-Request(Event-Request) is sent) or
[0062] 2--the S-CSCF requests money reservation to the OCS as
usual.
[0063] In step B1, the originating user equipment 2 sends an INVITE
message, similar to that sent in step S1 of FIG. 2. However, this
message will indicate that it is requested that the terminating
user equipment, user B, pay for the session.
[0064] In step B2, the S-CSCF 4 which is for user B and not the
originating user equipment, checks the SDP against the local media
policy. This corresponds to step S2 but is for user B.
[0065] In step B3, a message such as shown in step S3 is sent from
the S-CSCF/SCF of user B to the OCS handling user B. Either 1 or 2
above is executed.
[0066] In step B4, the OCS for user B check the user's balance in
the account for user B and determines the media policy for user B,
i.e. whether or not certain media components and/or services should
be dropped or continued. Alternatively the OCS may determine that
user B is not allowed to pay for a connection initiated by another
party. This corresponds to step S4 of embodiment 1.
[0067] In step B5 the OCS 6 either sends a message such as shown in
step S5 if user B will pay. This message may contain service units
and possibly media policy if applicable (i.e. if not enough funds
in the user's account).
[0068] The S-CSCF/SCF sends a message in step B6 to the originating
user equipment 2. This is as shown in step S6 in embodiment 1.
Alternatively, information will be provided if user B payment has
been refused by the network or the OCS either for lack of funds or
because user B is not paying for the session.
[0069] In step B7, this is the same as step S7 shown in FIG. 2.
[0070] The next step B8 is the same as S8 shown in FIG. 2 but the
message additionally includes information indicating that user B is
to pay for the request.
[0071] Step B9 and B10 are the same as steps shown in FIG. 2 and
correspond to step S9 and S10 respectively.
[0072] If the request for payment by user B is refused, then the
user making the request may request the services again, but this
time with the user making the request paying for the
connection.
[0073] Session modification for an existing session may be
performed by any of the parties involved. The re-INVITE request can
negotiate new medias within the existing dialog, medias may be
added or dropped. If some media is dropped from the existing
dialog, the charged UE can assume that the session modification
complies with the possibly received media policy (OCS determined).
However, the charged UE will not add any media if the addition of
this media should cause the session to exceed the media policy
received from the network.
[0074] In the described embodiments, where a user has been refused
a component and/or service requested for lack of funds, the user
may be provided with a messaged indicating this. In this way the
user will know that his account needs refilling potentially and he
will not mistaken attribute failures to receive all the services
with network problems.
[0075] In embodiments of the invention, not only can the account of
a user be taken into account when determining which medias are
allowable but also which media are allowed in the network. For
example, step S2 may determine if the requested media are allowed
in the network.
[0076] There may be no restriction on the services and service
components available to a user if the user has over a certain
amount of funds in his account.
[0077] The media policy for a particular user may vary with time as
the amount of money in the user's account changes.
[0078] It should be appreciated that embodiments of the present
invention have been described in the context of IMS system.
Embodiments of the invention have a wider application and can be
used in any appropriate system.
[0079] It should be appreciated that different entities may perform
the same function as the OCS in different embodiments of the
invention. For example a CSCF may provide the functions.
[0080] In one modification to the invention, where the connection
is modified to drop one or more components and/or services, the
user may be allowed to indicate if he wishes to proceed with the
modified connection, before the connection is established.
[0081] It should be appreciated that the functions of the
S-CSCF/SCF may be carried out by both these entities or either one
of these entities depending on implementation.
[0082] Embodiments of the invention can also be used in charging
schemes where a user pays in arrears for services which are
provided. For example, the user may be set a threshold for the
amount of charges which have accumulated or the amount of charge
which can be incurred for a single connection.
[0083] It is noted herein that while the above described are
exemplifying embodiments of the invention, there are several
variations and modifications which may be made to the disclosed
solution without departing from the scope of the present invention
as defined in the appended claims.
* * * * *