ITU-T Q 956 3-1995 Integrated Services Digital Network (ISDN) - Stage 3 Service Description for Charging Supplementary Services Using DSS 1 Clause 3 - Reverse charging (Study Group.pdf

1、INTERNATIONAL TELECOMMUNICATION UNION)45G134 1 TELECOMMUNICATION (10/95)STANDARDIZATION SECTOROF ITU$)4!,G0G035“3#2)“%2G0G03).!,).3934%-G0G0.O G0G0 ).4%2!4%$G0G03%26)#%3G0G0$)4!,G0G0.%47/2+)3$.G9G0G0 G0G034!%G0G0 G0G0$%3#2)04)/.G0G0 Case B: Reverse charging for the rest of the call requested by the

2、calling user or the called user during theactive phase of the call; Case C: Reverse charging for the entire call requested by the called user during the active phase of thecall; Case D: Reverse charging unconditional.NOTE The calling user should not be provided with a bearer connection until the opt

3、ion of charging, either normal orreversed has been resolved.The REV supplementary service is applicable to all telecommunication services.Further part(s) of this Recommendation shall specify the method of testing required to identify conformance to thisRecommendation.This Recommendation is applicabl

4、e to equipment, supporting the REV supplementary service, to be attached at eitherside of a T reference point or coincident S and T reference point when used as an access to the public ISDN.3.2 ReferencesThe following Recommendations and other references contain provisions which, through reference i

5、n this text, constituteprovisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendationsand other references are subject to revision: all users of this Recommendation are therefore encouraged to investigate thepossibility of applying the most recen

6、t edition of the Recommendations and other references listed below. A list ofcurrently valid ITU-T Recommendations is regularly published.1 ITU-T Recommendation I.411 (1993), ISDN user-network interfaces Reference configurations.2 CCITT Recommendation I.130 (1988), Method for the characterization of

7、 telecommunication servicessupported by an ISDN and network capabilities of an ISDN.3 ITU-T Recommendation I.112 (1993), Vocabulary of terms for ISDNs.2 Recommendation Q.956 (10/95)4 ITU-T Recommendation Q.932 (1993), Digital Subscriber Signalling System No. 1 (DSS 1) - Genericprocedures for the con

8、trol of ISDN supplementary services.5 ITU-T Recommendation Q.931 (1993), Digital Subscriber Signalling System No. 1 (DSS 1) - ISDNuser-network interface layer 3 specification for basic call control.6 CCITT Recommendation X.208 (1988), Specification of Abstract Syntax Notation One (ASN.1).7 CCITT Rec

9、ommendation X.219 (1988), Remote operations: Model, notation and service definition.8 ITU-T Recommendation I.210 (1993), Principles of telecommunication services supported by an ISDN and themeans used to describe them.9 ITU-T Recommendation clause 1/Q.954 (1993), Stage 3 description for multiparty s

10、upplementary servicesusing DSS 1, Clause 1 Conference Calling.10 ITU-T Recommendation clause 2/Q.956 (1995), Stage 3 description for charging supplementary servicesusing DSS 1, Clause 2 Advice Of Charge (AOC).11 ITU-T Recommendation clause 4/Q.953 (1995), ISDN stage 3 description for call completion

11、 supplementaryservices using DSS 1, Clause 4 Terminal Portability.12 CCITT Recommendation Z.100 (1988), Specification and description language.13 ITU-T Recommendation clause 3/Q.736 (1995), Stage 3 description for charging supplementary servicesusing Signalling System No. 7, Clause 3 Reverse chargin

12、g (REV).3.3 DefinitionsFor the purposes of this Recommendation, the following definitions apply.3.3.1 basic telecommunication service: A bearer service or teleservice. The term “bearer service” and “teleservice”are defined in 2.2/I.112 3, definitions 202 and 203.3.3.2 called user: The called user is

13、 the user to whom an incoming call is offered.3.3.3 calling user: The calling user is the user initiating an outgoing call at the originating interface.3.3.4 invoke component: See 8.2.3.1.1/Q.932 4.3.3.5 network: The DSS 1 protocol entity at the network side of the user-network interface.3.3.6 no tr

14、ansfer mode: This indicates that the charging function is done at the originating side when the ReverseCharging is invoked.3.3.7 reject component: See 8.2.3.1.1/Q.932 4.3.3.8 return result component: See 8.2.3.1.1/Q.932 4.3.3.9 return error component: See 8.2.3.1.1/Q.932 4.3.3.10 service; telecommun

15、ications service: See 2.2/I.112 3, definition 201.3.3.11 supplementary service: See 2.4/I.210 8.3.3.12 transfer mode: This indicates that the charging function is done at the destination side when the ReverseCharging is invoked.3.3.13 user: The DSS 1 protocol entity at the user side of the user-netw

16、ork interface.3.4 AbbreviationsFor the purposes of this Recommendation, the following abbreviations are used.Fac Facility information elementINV Invoke componentNot.ind. Notification indicator information elementRecommendation Q.956 (10/95) 3N(R) “Reverse charging (For the rest of the call)” notific

17、ation descriptionN(W) “Reverse charging (Whole call)” notification descriptionRE Return Error componentRR Return Result componentREV Reverse ChargingREV-I REVIndication operationREV-R RequestREV operationREV-T REV-T-Status operation3.5 DescriptionCase AThis supplementary service allows a calling use

18、r, on a per-call basis, to request reverse charging at call set-up time andthe called user to accept or reject the charges.If the REV supplementary service request is rejected by either the network or the called user, the call shall be cleared.When the calling user does not explicity request reverse

19、 charging, the calling user is charged as normal.In order to use this supplementary service, the calling and the called users need to have the capability to request andaccept respectively the REV supplementary service.Case BThis supplementary service allows a calling and a called user, to request re

20、verse charging during the active phase of thecall. When the calling user requests this supplementary service, the called user is allowed to accept or reject the charges.If the REV supplementary service request is rejected by either the network or the called user, the call remains unaffected.With thi

21、s supplementary service, the usage-based charges are charged to the called user from the moment of theacceptance of the request.In order to use this service, the calling and the called users need to have the capability to request and accept respectivelythe REV supplementary service if this service i

22、s requested by the calling user and the called user, needs to have thecapability for requesting the REV supplementary service if this service is requested by the called user.Case CThis supplementary service allows a called user before disconnection of the call, to request reverse charging for theent

23、ire call.If the REV supplementary service request is rejected, the call remains unaffected.When a called user does not explicitly request the REV supplementary service, the calling user is charged as normal.With this supplementary service, the usage-based charges are charged to be called user from t

24、he beginning of the call.In order to use this supplementary service, the called user needs to have the capability for requesting the REVsupplementary service.Case DThis supplementary service allows the called user to be charged for all incoming calls, or all incoming calls for apredefined set of bas

25、ic service. No user request is required.4 Recommendation Q.956 (10/95)3.6 Operational requirements3.6.1 Provision/withdrawalThe provision of one or more of the Cases A-D is a network option.The calling user does not need to subscribe to this supplementary service.This supplementary service is provid

26、ed either by a called users subscription or it is generally available.Call-by-call reverse charging and unconditional reverse charging are performed under the following condition:a) Call-by-call reverse charging (Cases A-C). Selection of called users subscription or generally available isa network m

27、atter.b) Unconditional reverse charging. Only provision by called users subscription should be provided, becausethe called user cannot reject reverse charging in this case.If the REV supplementary service is provided at a coincident S and T reference point, then it shall be provided on a perISDN num

28、bers basis.3.6.2 Requirements on the originating network sideThe normal procedures of Recommendation Q.931 5 apply, the extensions are defined below.Case AThe originating network shall be able to handle this supplementary service as described in 3.9.2.1.Case BThe originating network shall be able to

29、 handle this supplementary service as described in 3.9.2.2.Case CNo special requirement exists, except for the calling user notification.Case DNo special requirement exists, except for the calling user notification.3.6.3 Requirements on the destination network sideCase AThe destination network shall

30、 be able to handle this supplementary service as described in 3.9.2.1.Case BThe destination network shall be able to handle this supplementary service as described in 3.9.2.2.Case CThe destination network shall be able to handle this supplementary service as described in 3.9.2.3.Case DThe destinatio

31、n network shall be able to handle this supplementary service as described in 3.9.2.4.3.7 Coding requirements3.7.1 MessagesDepending on the requested REV Case, basic call control messages as well as the FACILITY and the NOTIFY messagesmay be used for operation of the REV supplementary service.Recomme

32、ndation Q.956 (10/95) 53.7.2 Additional information elements3.7.2.1 Coding of the Facility information elementTables 3-1 and 3-2 show the definition of the operations required for the REV supplementary service using ASN.1 asspecified in Recommendation X.208 6 and using the OPERATION macro as defined

33、 in Figure 4/X.219 7.The formal definition of the component types to encode these operations is provided in Recommendation Q.932 4.The inclusion of components in a Facility information elements is defined in 8.2.3/Q.932 4.3.7.2.2 Coding of the Notification indicator information elementThe Notificati

34、on indicator information element is used in Case B (requested by the called user), Case C and Case D forreverse charging notification; the network sends this notification to the calling user. See Table 3-3.TABLE 3-1/Q.956Coding of the facility information element for the REV supplementary servicewhe

35、n provided at the coincident S and T reference pointReverse-Charging-Service-Operations-and-Errors ccitt recommendation q 956 reverse-charging (3)operations-and-errors (1) DEFINITIONSBEGINEXPORTSIMPORTS:=RequestREV, REVIndication, UserIgnored, REVIsAlreadyRunning;OPERATION, ERRORFROMRemote-Operation

36、-Notation joint-iso-ccitt remote-operations (4) notation (0) userNotSubscribed, rejectedByNetwork, rejectedByUser, notAvailable,invalidCallState, basicServiceNotProvided,supplementaryServiceInteractionNotAllowed, resourceUnavailable,proceduralError,FROMGeneral-Error-List ccitt recommendation q 950 g

37、eneral-error-list (1) ;RequestREVREVIndication:= OPERATIONARGUMENT case CaseRESULTERRORS userNotSubscribed, rejectedByNetwork, rejectedByUser, notAvailable,invalidCallState, basicServiceNotProvided,supplementaryServiceInteractionNotAllowed, resourceUnavailable,proceduralError, UserIgnored, REVIsAlre

38、adyRunning := OPERATIONCase := ENUMERATED caseA(1), caseB(2), caseC(3) requestREV RequestREV := 60REVIndication := OPERATIONrEVIndication REVIndication := 61UserIgnored := ERRORREVIsAlreadyRunning := ERRORuserIgnored UserIgnored := 45rEVIsAlreadyRunning REVIsAlreadyRunning := 49END - of Reverse-Char

39、ging-Service-Operations6 Recommendation Q.956 (10/95)TABLE 3-2/Q.956Coding of the Facility information element for the REV supplementary service(for interworking with private ISDNs)TABLE 3-3/Q.956Codepoint in the Notification indicator information elementfor the REV supplementary service3.8 State de

40、finitionsThe following states are used in the dynamic description (SDL):REV idle: The REV supplementary service has not been requested.REV request: The REV supplementary service request has been made and is waiting for a response.REV indication: A message with a RequestREV invoke component has been

41、received.REV active: The REV supplementary service is active, i.e. the REV request has been positively acknowledged by thenetwork.These states are specified for the purpose of the protocol definition, they need not be provided in an implementation.3.9 Signalling procedures at the coincident S and T

42、reference point3.9.1 Activation/deactivation/registrationNot applicable.Reverse-Charging-Service-Private-Networks-Operation ccitt recommendation q.956reverse-charging (3) private-networks-operation (2) DEFINITIONSBEGINEXPORTSIMPORTS:=REV-T-Status;OPERATION, ERRORFROMRemote-Operation-Notation joint-i

43、so-ccitt remote-operations (4) notation (0) :REV-T-Status := OPERATIONARGUMENT status StatusStatus := ENUMERATED wholeCall(1), forTheRestOfTheCall(2) rEV-T-Status REV-T-Status := 62END - of Reverse-Charging-Service-Private-Networks-OperationNotification description (octet 3)Bits7 6 5 4 3 2 11 1 0 1

44、1 1 01 1 0 1 1 1 1Reverse charging (Whole call)Reverse charging (For the rest of the call)Recommendation Q.956 (10/95) 73.9.2 Invocation and operation3.9.2.1 Case A3.9.2.1.1 Normal operation3.9.2.1.1.1 Actions at the originating local exchangeTo request REV Case A, the calling user shall send to the

45、 network a SETUP message including a RequestREV invokecomponent indicating Case A in the Facility information element. The originating local exchange, receiving this requestin a SETUP message, shall check if this supplementary service can be provided, e.g.: supplementary service interaction is allow

46、ed (see 3.12); Signalling System No. 7 supports this supplementary service.If these checks are successful, the originating local exchange, forwards this information towards the network side, inassociation with the basic call request.3.9.2.1.1.1.1 Reception of REV acceptanceWhen the originating local

47、 exchange receives, from the network, the indication that the call and the REV supplementaryservice are accepted by the called user, it shall send to the calling user a CONNECT message including the RequestREVreturn result component in the Facility information element.The calling user shall not be c

48、harged for this call.If Case D applies at the called side, the originating local exchange receiving this indication from the network, shall sendto the calling user in the CONNECT message including, in addition to the RequestREV return result component, thenotification description “Reverse charging (

49、whole call)” in the Notification indicator information element (see 3.12.21).3.9.2.1.1.1.2 Reception of a call release indicationWhen the originating local exchange receives, from the network, a call release indication, it shall send to the calling usera DISCONNECT message with the Facility and Cause information elements indicating respectively the error (if any) andcause received from the network.3.9.2.1.1.2 Actions at the destination local exchange3.9.2.1.1.2.1