Charging mechanisms for ip multimedia services

<u style="single">Field of the invention</u> The present invention relates to a billing mechanism for IP multimedia services, which is particularly applicable, but not necessarily, to Push-to-talk over Cellular services.

<u style="single">Background of the present invention</u> IP multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By increasing the number of media that can be combined with basic applications, the number of services provided to end users will increase, and the experience of personal communication will be enhanced. This will bring about a new generation of personalized and richer multimedia communications services.

IP Multimedia Subsystem (IMS) is a technology defined by the 3rd Generation Partnership Project (3GPP), which provides IP multimedia services over 3G mobile communication networks. IMS provides key capabilities to enhance the end-user's personal communication experience through service integration and dialogue. IMS enables new and rich personal (client-to-client) and personal-to-content (client-to-server) communication over IP-based networks. This IMS uses Session Initiation Protocol (SIP) and Service Transport Protocol (SDP) to set up and control calls or sessions between user terminals (or user terminals and web servers). Figure 1 shows how IMS fits into a mobile network architecture.

Existing cellular telephone network operators have experienced a significant increase in the number of subscribers choosing to use so-called "prepaid" subscriptions in recent years. This "prepaid" subscription allows the subscriber to deposit the amount of cash (credit balance) to his or her operator, which is due to the subscriber's next use of the service. It is consumed. It is expected that prepaid subscription options will turn out to be as popular as users of IPMM services. In fact, the provision of prepaid services will be essential for widespread coverage in IPMM services.

When the online / real-time billing mechanism is used (for prepaid users), the general rule for the IPMM serving element (SE) that provides access to the requested service is the move node to that requested service. To request a credit inquiry before granting access to. However, as IPMM SE has to make credit inquiry transactions with billing control nodes, also known as prepaid systems (PPS) or online billing systems (OCS), session setup time for prepaid subscribers will inevitably increase. Will be.

Session setup time is important for some IMPP / IMS-based services. This applies to so-called Push-to-talk over Cellular (PoC) services, such as instant personal talk and ad hoc instant group talk. This requires the caller to operate the PoC button on his device to invite one or more users to a walkie-talkie type session and instantly contact the invited party / party group. (For traditional outgoing calls, calls, and responses based on telephony services). The introduction of the currently proposed prepaid payment mechanism can exacerbate PoC session setup times to unacceptable levels. Alternatively, due to the additional delays that occur during the credit inquiry phase, the user may experience a suboptimal experience.

<u style="single">Abstract of the present invention</u> An object of the present invention is to prevent the influence of a prepaid payment mechanism at an actual and permissible level of subscriber service.

According to the first configuration of the present invention, there is provided a method of reserving credits to mobile subscribers for IP multimedia services.

This method Continue the initial registration of the subscriber of the IP multimedia service prior to the activation of the IP multimedia service. The early session establishment process is used to reserve the credit amount on the billing control node and notify the IMP multimedia serving element of the credit reservation. Upon activation of the IP multimedia service, the IP multimedia serving element can immediately transition to the early session establishment process. It is characterized by that.

It will be clear that the early session establishment process will include the exchange of appropriate messages between the IP multimedia serving element and the billing node. This message satisfies the specifications of the DIAMETER protocol.

The early session establishment process will also typically be used for service negotiation purposes (eg, media address and codec type) between the subscriber's terminal (UE) and the IMS server.

The session establishment process can be automatically started following the registration of the subscriber of the IP multimedia service. Alternatively, the session establishment process can be initiated, for example, by a subscriber / end user activating a particular IP multimedia service on his or her terminal.

The present invention is not particularly required, but is applicable to push-to-talk overcellular (PoC) IP multimedia services.

The method includes estimating an appropriate amount of credit for the IP multimedia service at one of the IP multimedia serving element and the billing control node. Preferably, this estimate is performed on the billing control node.

In the case of a prepaid subscriber, the billing control node is a prepaid system (PPS) server located on the subscriber's home network.

Preferably, the method performs a credit inquiry between the IM multimedia service element and the billing control node based on the actual service requesting / activating the adjusted credit amount when the IP multimedia service is started. Execute the process. The estimated credit amount is replaced with the adjusted credit amount.

According to a second configuration of the present invention, there is provided a method of controlling an IP multimedia serving element that is configured to facilitate access to a mobile subscriber's IP multimedia services. This method Prior to the start of the IP multimedia session, the initial registration of the subscriber of the IP multimedia service is continued, the early session establishment process with the billing control node is started, and the credit amount is reserved in the billing control node. It is characterized by that.

According to a third configuration of the present invention, there is provided a method of controlling a billing control node configured to control subscriber access to an IP multimedia service. This method Prior to the activation of the IP multimedia service, the billing control node participates in an early session establishment process that continues the initial registration of the subscribers of the IP multimedia service, and the billing control node is appropriate to reserve for future sessions. Estimate the amount of credit It is characterized by that.

Detailed description of embodiments of the present invention In an IP Multimedia Subsystem (IMS) session, there can be a number of users who are subscribers to several different IMS operators. In any generally applicable billing process, each IMS operator should be able to charge its own subscribers according to its own billing policy. In other words, different billing models may be applied to different networks for the same IMS session. Also, different billing models may apply to different sets of subscribers for the same IPMM service / feature within a given operator's network.

According to the 3GPP R5 TS 32.225 and TS 32.200, and the IETF DCC (Internet Draft "Diameter Credit Control Application"), there are two situations for IMS online billing.

1) "One-Time Event with Direct Debiting" status. "Immediate Event Charging" model in 3GPP. "Credit Authorization with Direct Debiting" model in the IETF DCC.

2) "Session-based credit control" status. "Event Charging with Unit Reservation" model in 3GPP. The IETF DCC "Credit Authorization with Money Reservation" model.

In both models, the IPMM Serving Element (IPMM SE), or credit control client, is an online billing system (OCS) / prepaid system (PPS), or credit control, before allowing the service to be delivered to the end user. Request a credit inquiry from the server. The session-based credit control situation has been considered to be more appropriate for most IPMM services, which is the situation considered herein.

Session-based credit control allows PPS to rate requests from IMPP SE, reserve the appropriate amount from the user account, and IPMM SE the corresponding amount of credit resources. This is the process when notifying to. Of course, "credit resource" does not have to mean that it is an actual monetary credit, even if the credit resource is given in the form of a be metered unit (amount of data or time). Good. Upon receiving a successful response to a credit inquiry in terms of the amount of credit resources, IPMM SE will allow the service to be delivered to the end user and begin monitoring the use of the given resources. IPMM if the credit resources allowed to the end user are consumed, or if the service is successfully delivered or terminated The SE reports the usage to the PPS, which deducts the usage from the user account (if the service continues to be delivered, the PPS performs the rating and reserves new credits). This process includes the first query, preferably an intermediate query, and a final query. Both IPMM SE and PPS are required to maintain credit inquiry status information.

The upper part of Figure 2 shows a typical online billing architecture for IPMM, while the lower part of that figure shows a simplified architecture for PoC. Online billing systems (OCS) / prepaid systems (PPS) provide billing control capabilities for real-time billing mechanisms. The prepaid system includes account balance manager and user account (user account), rating engine and tariff information. The rating engine provides rating values for unpriced sessions / services or sources, i.e., those for which the serving element does not charge. For online billing, the IPMM SE group that can provide billing input to PPS is the Serving-Call Session Control (S-CSCF). Function), multimedia resource function control (MRFC) and application server (AS). For cellular overpush-to-talk (PoC), the SE that provides billing input to the PPS is a PoC server (which employs MRF and AS functions). The interface between the IPMM SEs and PPS is based on the Diameter-based Protocol (DBP) and Diameter Credit Control Application (DCC), as defined by Releases 5 and 6 of 3GPP.

Figure 3 shows the PoC Release 2 architecture, where the PoC functional entities are shown in solid lines. The following interface is shown in Figure 3.

It: Floor (Speaking right: floor) Control medium (Media: media) Itn: Floor control and medium Is: PoC client-to-proxy session signaling If: Proxy to PoC server session signaling In: Proxy-to-proxy session signaling Im: Group Management Server vs. PoC Client Ik: Group management server vs. PoC server Io: OTAP server vs. PoC client The PoC architecture has two PoC server functions, a controlling PoC server function / logical entity and a participating PoC server function / logical entity. For each PoC talk session, there is only one controlling PoC server. In contrast, there can be one or more participating PoC servers. The control PoC server handles centralized tasks. This task should not be handled by more than one PoC server in a PoC talk session. The PoC server operates as either a control PoC server or a participating PoC server. This is selected on a per PoC talk session basis.

A PoC server implementation (ie, a physical entity / node) may act as both a controlling PoC server and a participating PoC server simultaneously and for the same PoC talk session. In the case of instant personal talk and ad hoc instant group talk, the PoC server of the invited user is the control PoC server. In the case of chat group talk and instant group talk, the controlling PoC server is the PoC server that owns / manages the group identity (global group identity). Further details on these PoC services are given in the appendix below.

As mentioned above, credit for PoC sessions The traditional method for reservation) can result in significant session setup delays. Another method of retaining credit for PoC delay detection services / features (ie, Instant Personal Talk and Ad Hoc Instant Group Talk) is proposed herein. It maintains all prepaid characteristics (ie, operator credit control, end-user real-time consumption control). This method uses the so-called "early session" establishment process to allow the PoC function at a critical session setup time before the end user initiates a talk session, i.e., before the actual PoC function is activated. The credit for the session is reserved. The early session establishment process is used for service negotiation purposes between the UE and the user's own home PoC server (eg, IP address / port number and codec type communication for RTP / RTCP). This early session can be established immediately following IMS registration or at any time thereafter. Early session establishment process, PoC establishment process is defined in PoC resource 2.0 architecture.

For early session establishment, the PoC server sends a Diameter Accounting Request (ACR) with Accounting-Record-Type = START before continuing to process the Early Session Establishment request. By doing). The PPS will tentatively rate the service (at this point it is not known which PoC feature will be activated by the user at a later time) and if the user's credit balance is sufficient, the PPC will be from the user account. Reserve the appropriate amount and return the corresponding credit unit amount to the PoC server (Accounting-Record-Type = START is used in the Diameter ACA message). If the credit reservation is successful, the PoC server will continue to process the early session establishment request. Here, the PoC feature has not yet been activated, so this credit inquiry phase is not particularly time-sensitive.

When credit reservation fails (for example, the user's credit balance is exhausted), PPS initiates immediate service termination processing by returning a failure instruction to the PoC server (Result in Diameter ACA message). -Code = DIAMETER_END_USER_SERVICE_DENIED is used). The PoC server sends the SIP error indication back to the serving IMS core. The error instruction is returned to the UE and the end user.

As mentioned above, if credit is reserved for early session establishment, the PoC server will either activate which PoC function at a later time, or the UE that executes the early session establishment process will make a call (session owner) or I still don't care about the facts about whether it will be used by the end (participation) end user. In other words, with early session establishment, the PoC server only needs to impose input restrictions to rate the prepaid system. In a session connection (ie, the actual PoC function activation / setup stage), the PoC server immediately processes the service request based on the credits reserved in advance. Here, the PoC server can provide the PPS with accurate input for the rating (Accounting-Record-Type = in the Diameter ACR message). Use INTERIM). This credit inquiry phase is also less time constrained. This is because the estimated amount of credit is already reserved, reducing the risk to the service provider. While the service launch can be processed immediately, in parallel with this, the next credit inquiry is performed to improve the rating.

Figure 4 shows the signaling involved in the early session establishment process when used for improved credit queries using the instant personal talk feature. This situation gives for early session establishment processing between both sides (note that the signaling flow does not show outgoing and incoming IMS cores). Each signaling step is shown below.

<u style="single">Network A early session establishment</u> 1a. UE-A establishes an early session by sending SIP INVITE to PoC Server A via IMS Core A (immediately after or after some initial IMS registration, eg, the user UE. Start (ie, the UE sends a SIP INVITE to IMS Core A) when launching the Instant Talk service from. IMS Core A returns SIP100 "Triing" to UE A. IMS core A detects the outgoing trigger and, as a result, sends a SIP INVITE to PoC server A. SIP INVITE includes:

Request-URI user part set to pre-configured string "Ad-hocGroupRequest" Accept-Contact including the feature tag "+ g.poc.talkburt = TRUE" To = URI user part set to pre-configured string "Ad-hocGroupRequest" From = inviting user's Public User Identity Message body with Content Type "application / sdp" containing an SDP Offer 1 2a. PoC Server A checks if early sessions are supported. To assume this situation, assume that early sessions are supported. PoC server A sends a SIP100 triing to IMS core A.

<u style="single">Billing in network A, initial inquiry</u> 3a. The control PoC server starts a credit control session for user A's home prepaid system A and continues processing the received session setup request / SIP INVITE. The prepaid system A is identified by the ECF address. It was downloaded from the Home Subscriber System (HSS) to the IMS Core A S-CSCF as part of the User A profile when the IMS User A was registered, and at SIP INVITE, the IMS Core A S-CSCF. Is sent to PoC server A.

4a. The control PoC server sends the Diameter ACR to the prepaid system A. The Diamter ACR includes: :: Accounting-Record-Type = START_RECORD Subscription-Id (Type = END_USER_SIP_URL, Data ='user-A SIP URI') MSCC (# 1) Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_ANY_TALK_SESSION) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-owner) Requested-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='pre-configured value') Service-Parameter-Info (Type = ExtensionNumberA, Value = eg "total time session is up" MSCC (# 2) Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_ANY_TALK_SESSION) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-owner) Requested-Service-Unit (Type = SERVICE_CREDIT_EVENT, value ='pre-configured value') Service-Parameter-Info (Type = ExtensionNumberC, Value = eg "number of distributed talk bursts" MSCC (#n) Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_ANY_TALK_SESSION) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-participant) Requested-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='pre-configured value') Service-Parameter-Info (Type = ExtensionNumberBB, Value = eg "number of sent and / or received talk burst" Note: This example contains / shows three MSCC AVPs. In general, one of the measurement methods supported by IPMM SE for related service-type and party role combinations may include several MSCC AVPs.

5a Prepaid System-A tentatively ranks the service based on the content of the received service-parameter-info (at this stage, the service requested in the future is instant personal talk or Make a credit inquiry from an ad hoc instant group talk (I don't know if it's an ad hoc instant group talk), an end-user account (holding expected service charges), and reply a Diameter ACA message to the PoC server. To explain this situation, it is assumed that the user's credit balance is sufficient. This Diameter ACA includes: :: Result-Code = DIAMETER_SUCCESS Accounting-Record-Type = START_RECORD Accounting-Interim-Interval ('value set by the Prepaid System') Subscription-Id (Type = END_USER_SIP_URL, Data ='user-A SIP URI') MSCC (#a) Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_ANY_TALK_SESSION) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-owner) Granted-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='Prepaid System sets Granted-Service-Unit value = Requested-Service-Unit value') Service-Parameter-Info (Type = ExtensionNumberC, Value = eg "number of distributed talk bursts"). Note: This is a billing model that is useful when the user later takes on the role of session owner. MSCC (#b) Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_ANY_TALK_SESSION) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-participant) Granted-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='Prepaid System sets Granted-Service-Unit value = Requested-Service-Unit value') Service-Parameter-Info (Type = ExtensionNumberBB, Value = "sent talk burst"). Note: This is a billing model that is useful when the user later takes on the role of session participant.

Control PoC Server A begins monitoring the use of the granted-service-units.

<u style="single">Early session establishment procedure</u> 6a. PoC Server A sends SIP 202 Accepted to UE A via IMS Core A. This SIP202 accepted includes: Contact, containing the transient ad-hoc group identifier generated by the Controlling PoC Server Message body with Content Type "application / sdp" containing an SDP Answer 1 7a.UE A sends a SIP ACK to the PoC server via IMS core A.

<u style="single">Network B Early session establishment and initial billing inquiry</u> In parallel with steps 1a to 7a in network A, steps 1b to 7b occur in network B (including user B, UE B, IMS core B, PoC server B, and prepaid system B).

<u style="single">Early Session-Connect</u> After the early session establishment process shown in FIG. 4 is completed, the connection process is started by the subscriber (UE-A in this case). Figures 5 and 6 show the signaling involved in establishing an instant personal talk (ie, connecting setup). Again, this signaling flow does not show outgoing and incoming IMS cores. The signaling steps are as follows:

<u style="single">Connection setup with early session</u> 1. The UE A end user, Network A subscriber, operates the PoC button to start an instant personal talk session with the UE B end user, Network B subscriber.

2. UE-A sends SIP REFER to PoC server A via IMS core A. SIP REFER includes: :: Refer-To: invited user's Public User Identity (ie SIP URI or E.164 number) 3. Caller Participation PoC Server A recognizes the session type as an instant personal talk based on the information in SIP REFER (ie, public user identity).

The calling party participating PoC server A acquires the function of the control PoC server. The caller participation PoC server function is logically located in the same location as the control PoC server function. That is, for instant personal talk, the PoC server assigned to the invited user is the control PoC server.

The control PoC server is: Authorize invited users for talk sessions and Interpret SIP REFER as a potential subscription request to a reference (criteria) event package for each outgoing SIP INVITE / REFER (ie, the invited UE receives information about the invited user's final SIP response in SIP NOTIFY. ), Then interpret SIP REFER as a potential "floor request".

<u style="single">Billing on network A, intermediate inquiries</u> 4. The control PoC server executes an intermediate query to provide new / additional rating input to billing system A. That is, the control PoC server has the knowledge here that the session type is instant personal talk.

5. The control PoC server sends the Diameter ACR to the prepaid system A. The Diameter ACR includes: :: Accounting-Record-Type = INTERIM _RECORD Subscription-Id (Type = END_USER_SIP_URL, Data ='user-A SIP URI') MSCC Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_INSTANT_PERSONAL_TALK) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-owner) Requested-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='pre-configured value') Used-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='amount of used service units') Service-Parameter-Info (Type = ExtensionNumberC, Value = eg "number of distributed talk bursts") 6. Prepaid System A deducts usage from the end user's account, ranks the service based on the content of the received service-parameter-info, and ranks the service based on the end user's account (service charge). Make a new credit inquiry and reply to the Diameter ACA. In this situation, the user's credit balance is sufficient. This Diameter ACA includes: :: Result-Code = DIAMETER_SUCCESS Accounting-Record-Type = INTERIM _RECORD Accounting-Interim-Interval ('value set by the Prepaid System') Subscription-Id (Type = END_USER_SIP_URL, Data ='user-A SIP URI') MSCC Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_INSTANT_PERSONAL_TALK) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-owner) Granted-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='Prepaid System sets Granted-Service-Unit value = Requested-Service-Unit value') Service-Parameter-Info (Type = ExtensionNumberC, Value = eg "number of distributed talk bursts") 7. Control PoC Server A continues to monitor the use of Granted-service-units.

8. Control PoC Server A sends SIP 202 Accepted to UE A via IMS Core A.

9. Control PoC server A sends SIP INVITE (SDP Offer 2) to participating PoC server B. It will be appreciated that following the receipt of the SIP REFER message from UE A, this message can be immediately sent by PoC Server A. That is, this message may be sent before or between (5 and 6) the DIAMETER message.

10. Participating PoC server B gets the Do-not-Disturb flag (from the GLMS function), the access (accept / deny) list, and the answer mode of the invited user. Participating PoC server B authorizes the request based on the Do-not-Disturb flag and the invited user's access (accept / deny) list. In this situation, Participating PoC Server B determines that the DnD flag is not set, the invited user is not on the deny list, and the invited user's answer mode is set to "automatic answer". To do.

<u style="single">Billing in network B, intermediate inquiries</u> 11. The participating PoC server executes an interim query to provide new / additional rating input to billing system A. That is, the participating PoC server has knowledge of the end of the PoC session here.

12. The participating PoC server sends the Diameter ACR to the prepaid system B. The Diameter ACR includes: :: Accounting-Record-Type = INTERIM _RECORD Subscription-Id (Type = END_USER_SIP_URL, Data ='user-A SIP URI') MSCC Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_ANY_TALK_SESSION) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-participant) Requested-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='pre-configured value') Used-Service-Unit (Type = SERVICE_CREDIT7_EVENT, Value ='amount of used service units') Service-Parameter-Info (Type = ExtensionNumberBB, Value = "sent talk burst") 13. Prepaid System B deducts usage from the end user's account, ranks the service based on the content of the received Service-Parameter-Info, and gives the end user's account (service charge). Make a new credit inquiry and reply to the Diameter ACA. In this situation, the user's credit balance is sufficient. This Diameter ACA includes: :: Result-Code = DIAMETER_SUCCESS Accounting-Record-Type = INTERIM _RECORD Accounting-Interim-Interval ('value set by the Prepaid System') Subscription-Id (Type = END_USER_SIP_URL, Data ='user-A SIP URI') MSCC Service-Parameter-Info (Type = ExtensionNumber1, Value = POC_ANY_TALK_SESSION) Service-Parameter-Info (Type = ExtensionNumber2, Value = session-participant) Granted-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='Prepaid System sets Granted-Service-Unit value = Requested-Service-Unit value') Service-Parameter-Info (Type = ExtensionNumberBB, Value = "sent talk burst") 14. Participating PoC Server B begins monitoring the use of authorized services-units.

<u style="single">Connection setup for early session procedures</u> 15. UE-B has an established early session and also has a set of auto-answer modes. That is, the participating PoC server B has selected the early media mode.

16. Participating PoC server B sends SIP 200 OK (SDP Answer 2) to the control PoC server.

17. The SIP ACK is sent from the control PoC server A to the participating PoC server B. Note that, as with SIP INVITE message (9), sending SIP ACK and SIP 200 OK messages is independent of exchanging DIAMETER messages (5, 6, 12, 13).

18. The control PoC server sends the RTCP "floor acquired" to UE B via the participating PoC server B.

19. "Listen (receive) instruction" is given to user B.

20. The Control PoC Server sends RTCP "Floor Allowed" to UE A. Similar to SIP INVITE message (9), sending RTCP "floor acquired" (18) and RTCP "floor allowed" is independent of exchanging DIAMETER messages (5, 6, 12, 13). Please note.

21. "Talk instructions" are given to User A (both "SIP202 accepted" to carry the SDP response and "RTCP floor allowed" to indicate the PoC server are ready to be passed to the media. Also, these are needed for user interaction purposes).

<u style="single">Start of user A talking</u> 22. User A starts the talk.

23. "RTP Talk Burst" (media) is transmitted from UE A to UE B via the controlling PoC server and the associated PoC server B.

24. User A listens to (receives) User B's speech phrase.

25. Due to the previous "implicit (indirect) enrollment status of invited users" upon receipt of SIP 200 OK, the controlling PoC server sends a SIP NOTIFY request to IMS core A. IMS core A sends SIP NOTIFY to UE A. SIP NOTIFY includes: :: Event = refer Message body with Content Type "message / sipfrag" containing: The status line of the SIP response that the PoC Server received from the invited user, "SIP / 2.0 200 OK" for this scenario; and The Public User Identity of the invited user (SIP URI or MSISDN) 26. UE A sends SIP 200 OK to IMS Core A for SIP NOTIFY. IMS core A sends a SIP 200 OK to the control PoC server.

<u style="single">End of user A talking</u> 27. User A releases the PoC button.

28. UE A sends "RTCP floor release" to the control PoC server.

29. The control PoC server sends "RTCP floor idle" to UE A.

30. The control PoC server sends an "RTCP floor idle" to the participating PoC server B. This participating PoC server B also sends it to UE B.

31. A "floor idle instruction" is given to user B.

<u style="single">More talk bursts may be transmitted / received by User A and User B.</u> Other talk bursts may be transmitted / received by User A and User B.

Other credit control intermediate inquiries may occur.

<u style="single">Disconnection of talk session by user A</u> 32. User A requests to disconnect the talk session.

33. UE-A sends "RTCP BYE" to the control PoC server.

34. The control PoC server detects the expiration of the inactivity timer. According to the session termination policy, the controlling PoC server requests to cancel the talk session.

35. The control PoC server sends "RTCP BYE" to the participating PoC server B. This POC server B also sends it to UE-B.

36. A session disconnection instruction is given to user B.

37. The control PoC server sends SIP BYE to participating PoC server B.

38. Participating PoC Server B responds with SIP 200 OK (to SIP BYE).

<u style="single">Billing in network A, final inquiry</u> 39. The control PoC server sends a Diameter ACR to the prepaid system A. The Diameter ACR includes: :: Accounting-Record-Type = STOP_RECORD Subscription-Id (Type = END_USER_SIP_URL, Data ='user-A SIP URI') Used-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='amount of used service units') 40. Prepaid System A replies to Diameter ACA. In this situation, the user's credit balance is sufficient. This Diameter ACA includes: :: Result-Code = DIAMETER_SUCCESS Accounting-Record-Type = STOP_RECORD<u style="single">Billing in network B, final inquiry</u> 41. The participating PoC server sends the Diameter ACR to the prepaid system B. The Diamter ACR includes: :: Accounting-Record-Type = STOP_RECORD Subscription-Id (Type = END_USER_SIP_URL, Data ='user-A SIP URI') Used-Service-Unit (Type = SERVICE_CREDIT_EVENT, Value ='amount of used service units') 42. Prepaid system B replies to Diamter ACA. In this situation, the user's credit balance is sufficient. This Diameter ACA includes: :: Result-Code = DIAMETER_SUCCESS Accounting-Record-Type = STOP_RECORD It will be clear from the above explanation that the prepaid function (a mandatory PoC function to be widely accepted in the market) is introduced so that the credit inquiry phase does not affect the PoC talk session setup time. The IPMM serving element (eg, PoC server) is sometimes a PoC service feature (ie, instant personal talk, ad hoc) where the actual setup time is important after initial IMS user registration as part of "PoC early session processing". Performs a credit inquiry for the prepaid system and reserves credits before the (Instant Group Talk) is launched by the end user. When the end user activates the PoC service function, the IPMM serving element can process the service request immediately by utilizing the pre-reserved credit. At the same time, the IMPP serving element performs the following credit query to provide the prepaid system with readjusted rating input (eg, the actual activated PoC function, the role of the session originator). This ensures that the credit inquiry phase does not affect the PoC talk session setup time.

It will be apparent to those skilled in the art that the above embodiments can be variously modified without departing from the scope of the present invention.

<u style="single">Appendix</u> Cellular Overpush to Talk (PoC) is a "walky-talkie" type of service based on IMS technology. The PoC service includes the following functions. ::<u style="single">Instant personal talk</u> This is (one-to-one) voice communication with others. This means that the user talks with another person at the same time. The user invites other users to establish an instant personal talk session. Participating users of the one-to-one instant personal talk service can establish one-to-N communication (ie, ad hoc instant group talk) by adding new users or groups of users to the session.

<u style="single">Chat group talk</u> This is 1-to-N voice communication. This means that the user talks with another person at the same time. The user joins a group to join a chat group talk. That is, each participant individually joins the session. There are two types of chat groups. :: 1. An open chat group is a group that any user can join.

2. A restricted chat group is a group in the member list, and only users who belong to that group can add or remove group members. Also, only members of the group can participate in the chat group talk session.

Restricted Chat Group Before a talk can be established, a group must be created and members must be defined. Open Chat Group A group must be created before a talk can be established. Participants in an ongoing open or restricted chat group talk session can add or invite other users to the session. If a group is restricted, participants may only invite users who are members of that group.

<u style="single">Instant group talk</u> This is 1-to-N voice communication. This means that the user talks with another person at the same time. One member of the group invites all members of the other group to an instant group talk session. Before the instant group talk is established, the group must be created and the members must be defined. Members of a group that is out of the group or initially refused to be invited can join / rejoin an ongoing Instant Group Talk session. Participants in an ongoing Instant Group Talk session can add / invite other members of the group to the session.

<u style="single">Ad hoc instant group talk</u> This is 1-to-N voice communication. This means that the user talks with another person at the same time. The user invites the selected user to an ad hoc instant talk session. Participants in an ongoing Ad Hock Instant Group session can add / invite other users to the session. Users who are out of the group or initially denied an invitation can join / rejoin an ongoing Ad Hock Instant Group Talk session.

<u style="single">Instant personal alert</u> A user can alert another user. This alert expresses that the user wants to communicate, and is also a method of politely requesting another user to call back, for example, using the instant personal talk function. Instant personal alerts can also carry text messages.

In addition, the following features are used in connection with the PoC features described above. ::<u style="single">Group and list management</u> This allows PoC end users (and operators) to manage groups, lists and other information, as described below. This information is stored in group and list management server (GLMS) logical entities in the network and is managed via the UE-GLMS interface.

<u style="single">Contact list</u> These are used to store contact entries (individuals and groups) within the UE and network. This strike is used by the UE to address the user and group when initiating PoC communication. Contact lists apply to instant personal talk types and ad hoc instant group session types.

<u style="single">Access (accept / deny) list</u> These are used to define access rules. That is, it indicates who is allowed or not allowed to reach a particular user through the PoC service (ie, incoming / invited users use the accept / deny list). , Can accept or reject incoming talk session requests from other users). Access lists apply to all talk session types and are used by the PoC server. This is a call / termination side (party) function.

<u style="single">Group list</u> Group lists are used to define PoC specific groups and apply to open / restricted chat group talks and instant group talks. It is used by the PoC server and UE.

<u style="single">Do-not-Disturb (DnD)</u> Incoming / invited users can use the "Do Not Disturb" feature to block all incoming talk sessions (other than instant personal alerts). DnD takes precedence over access lists. It is used by the PoC server. This is a call / termination side (party) function.

<u style="single">Answer mode</u> The incoming / invited user can choose between automatic and manual answer modes, which are used by the PoC server and UE. This is a call / termination party feature. PoC servers servicing invited users can use answer mode to select the media mode (early or delayed media) for the session.

<u style="single">Presence</u> This feature is used to advertise (notify) the accessibility of other parties to the parties.

<figref num="1">It is a figure which shows the mobile network architecture which incorporates an IP multimedia subsystem.</figref><figref num="2">It is a figure which shows the logical online billing architecture for IPMM service.</figref><figref num="3">It is a figure which shows the PoC release 2 architecture.</figref><figref num="4">It is a figure which shows the signaling related to the early session establishment processing for PoC instant personal talk.</figref><figref num="5">It is a figure which shows the signaling related to the session connection processing following the early session establishment when a service is actually started.</figref><figref num="6">It is a figure which shows the signaling related to the session connection processing following the early session establishment when a service is actually started.</figref>