PHS MoU Document
B-IF3.51-01-TS
Title: Personal Handy-Phone System : Network-Network Interface forCall Control -PHS-UUS Supplementary ServiceVersion: 01
Date: July 14, 1999
PHS MoU Classification: Unrestricted
List of contents:
PHS User-to-User Signalling(UUS)
1.1 PHS User-to-User Signalling service 1
1.2 PHS User-to-User Signalling service 2
1.3 PHS User-to-User Signalling service 3

Number of pages: 30

PHS MoU Group
c/o Association of Radio Industries and Businesses (ARIB)
14F, Nittochi Bldg., 4-1, Kasumigaseki 1-choume, Chiyoda-ku, Tokyo 100, Japan
TEL +81-3-5510-8599 FAX +81-3-3592-1103© PHS MoU Group1999

PHS MoU Document
B-IF3.51-01-TS
Version01

History of Revised Versions
Date
OutlineJuly 14, 1999

EstablishedB-IF3.51-01-TS
Personal Handy-Phone System
Network-Network Interface for Call Control-PHS-UUS Supplementary Service<Summary>
1.Relations with international standards
This specification specifies the network-network interface for call control for PHS-UUS
supplementary service based on ITU-T Recommendation Q.737.1
2.Differences from ITU-T Recommendation Q.737.1
The differences between this specification and ITU-T Recommendation Q.737 .1 are summarized in
the following table.
Table Summary-1/B-IF3.51 Differences from ITU-T Recommendation Q.737.1
Item

Differences

1)Common terms

Reasons“ UUS” is changed toThis change conforms to“ PHS-UUS” .

B-SV2.70.

(1)Note for the packet bearer service is This change conforms to2)General
description

deleted.

B-SV2.70.

(2)Note for the networks only supporting
less number of user information isdeleted.

3)Interaction

with All descriptions are revised.

This change conforms to interaction

other

with

supplementary

supplementary

specified in B-SV2.70.

services

service4)Signaling flows(1)Signaling on DSS.1 are changed.
(2) Figure1-4/Q.737 is deleted.

(1)This change conforms to B-IF2.01
and B-IF2.02.
(2)This change conforms to BSV2.70 where Point-to-multipoint
arrangement is not specified.

B-IF3.51-01-TS(1)

3.References
ITU-T Recommendation Q.737.1,Q.730
PHS MoU Specification B-SV2.70,B-IF0.51,B-IF1.51, B-IF2.51, B-IF3.07
B-IF3.31 to 3.34, B-IF4.11 to 4.14

(2) B-IF3.51-01-TS

B-IF3.51-01-TS

Personal Handy-Phone System
Network - Network Interface for Call Control-PHS-UUS Supplementary Service-

Contents
PHS User-to-User Signalling (UUS) ........................................................................................1
1.1 PHS User-to-User Signalling service 1 .......................................................................1
1.2 PHS User-to-User Signalling service 2 .....................................................................10
1.3 PHS User-to-User Signalling service 3 .....................................................................20

B-IF3.51-01-TS

L1

PHS User-to-User Signalling (PHS-UUS)

1.1

PHS User-to-User Signalling service 1

1.1.1
Definition
The PHS User-to-User Signalling (PHS-UUS) supplementary service allows an PHS user tosend/receive a limited amount of information to/from another PHS user over the communication
channel in association with a call to the other PHS user.
1.1.2

Description

1.1.2.1 General description
PHS User-to-User Signalling service 1 is used to exchange information between two users as
described in PHS MoU Specification B-SV2.70 (stage 1). The functional description (stage 2) for thisservice can be found in PHS MoU Specification B-IF0..51. The stage 3 PS- public CS interface
protocol description is given in PHS MoU Specification B-IF1.51.The stage 3 public CS-ISDN
interface protocol description is given in PHS MoU Specification B-IF2.51. This clause is specific to
Signalling System No. 7 and use is made of the ISDN user part protocol defined in PHS MoUSpecifications B-IF3.31 to 3.34 and ITU-T Recommendation Q.730. Service 1 allows users tocommunicate by transferring user-to-user information within ISDN user part messages during the call
set-up and clearing phases. Up to 128 octets of user information may be transferred in each message.
The 128 octets do not include the user-to-user information parameter name, the protocol control
indicator or the length octets.
Service 1 is not a guaranteed service. If for any reason the combination of the basic andsupplementary service information causes the overall maximum length of the message to be exceeded
then if service 1 is included, the network shall perform segmentation of the ISUP message according
to 2/B-IF3.34..If the user-to-user information is to be discarded, the exceptional procedures as
described in 1.1.5.2.5.2 shall be applied if possible. The treatment given to the user-to-user
information parameter in the initial address message as described in this Specification is equallyapplicable to the case in which the user-to-user information parameter is carried in the segmentation
message after segmentation of the initial address message.
NOTE – For PHS User-to-User Signalling service 1, subsequent to initial acceptance orrejection of the service at the calling user, further actions may be required to confirm that the service
can be provided, or to indicate that it can no longer be provided (e.g. due to the presence of the Call
Forwarding on No Reply supplementary service). This Specification does not provide suchrequirements whose provision is for further study.
1.1.2.2 Specific terminology
user-to-user information (UUI): The information transferred by the PHS-UUS service.
user-to-user indicators (UUI ind): Indicators indicating request/acceptance/rejection of a PHS-UUS
service or discarding of user-to-user information.
1.1.2.3 Qualification on the applicability to telecommunication services
See PHS MoU Specification B-SV2.70.
1.1.2.4 State definitions
No specific state definitions are required.
1.1.3

Operational requirements

1.1.3.1 Provision/withdrawal
See PHS MoU Specification B-SV2.70.

B-IF3.51-01-TS1

1.1.3.2 Requirements on the originating network side
Not applicable.
1.1.3.3 Requirements in the network
No specific requirements are needed in the network.
1.1.3.4 Requirements on the terminating network side
Not applicable.
1.1.4
Coding requirements
User-to-user information is carried in the user-to-user information parameter of variable length which
may be contained in the initial address, address complete, call progress, connect, answer,
segmentation, and release messages.
An explicit request for service 1 is carried in the user-to-user indicators parameter in the initial address
message. An explicit indication of acceptance or rejection of service 1 is carried in the user-to-userindicators parameter in the address complete, call progress, answer, connect, or release messages.
The network indication when user-to-user information is discarded from the initial address message
according to 1.1.5.2.5.2.3, is carried in the user-to-user indicators parameter in the first appropriate
backward message, e.g. the address complete message.
1.1.5

Signalling requirements

1.1.5.1 Activation/deactivation/registration
PHS-UUS service 1 must be requested by the calling user at call set-up if UUI transfer is desired ineither direction.
Once a PHS-UUS service is activated (see Note), the network will accept UUI in both directions
according to the subscription of the calling user.
NOTE – Activation means request of PHS-UUS. Invocation means submission of UUI.
1.1.5.2 Invocation and operation
1.1.5.2.1 Actions at the originating local exchange
1.1.5.2.1.1

Normal operation

1.1.5.2.1.1.1 Implicit service request
Service 1 may be requested implicitly by the presence of the user-to-user information parameter in theinitial address message. An implicit request is “non-essential” by default.
Procedures for call set-up are as described in 2/B-IF3.34, with the following changes.
On call set-up, the initial address message will contain the user-to-user information parameter. The
user-to-user information will be received from call control and will be transported across the networkand delivered unchanged to the terminating call control for the called user. The user-to-user indicators
parameter will not be sent.
The reception of a user-to-user information parameter in a backward call control message from theterminating call control is an implicit indication of the acceptance of service 1.
1.1.5.2.1.1.2 Explicit service request
Service 1 may be explicitly requested in an initial address message. As an option at call set-up, thecalling user may be able to specify whether the request for service 1 is essential or non-essential forthe call (i.e. whether the call should be completed or not if user-to-user information cannot be passed).
Procedures for call set-up are as described in 2/ B-IF3.34, with the following changes:

2

B-IF3.51-01-TS

–

–

–

On call set-up, the initial address message will contain the user-to-user indicators
parameter with service 1 indicated as “requested, essential” or “requested, not essential”,
as appropriate.
For an essential request the ISUP preference indicator will be coded “ISUP required”..
The service request will be received from call control and will be passed to the call
control at the terminating exchange.
If the network and called user can support the transfer of user-to-user information, aservice 1 acceptance will be returned to the originating exchange in an address complete,call progress, answer, connect, or release message with the indication “service 1
provided” in the user-to-user indicators parameter. This explicit indication shall be
forwarded to the call control at the originating exchange.

1.1.5.2.1.1.3 Transfer of user-to-user information
User-to-user information may be contained in any of the messages that may be transferred in the call
set-up and call release phases, independently of whether the service is requested implicitly or
explicitly, provided that the explicit service 1 has not been rejected or the request for the implicit
service 1 has not been discarded. If the explicit request for service 1 is included in the initial address
message, then any user-to-user information included shall be considered part of the explicit service.
The user-to-user information parameter received at the distant exchange in a release message is passed
to the call control for the remote user. In the case of simultaneous clearing of the call the releasemessage may not reach the distant exchange and the user-to-user information will be lost.
1.1.5.2.1.2 Exceptional procedures
The originating exchange shall be able to interpret the discard and rejection indications generated byany succeeding exchange and act accordingly (see 1.1.5.2.5.2).
1.1.5.2.2 Actions at the transit exchange
1.1.5.2.2.1 Normal operation
The information which is generated as described in 1.1.5.2.1.1 is passed unchanged.
1.1.5.2.2.2 Exceptional procedures
The information which is generated as described in 1.1.5.2.5.2 is passed unchanged. Rejection of an
explicit service request or discarding of user-to-user information (see 1.1.5.2.5.2) can also take placein the transit exchange.
1.1.5.2.3 Actions at the outgoing international gateway exchange
1.1.5.2.3.1 Normal operationSee 1.1.5.2.2.1.
1.1.5.2.3.2 Exceptional procedures
See 1.1.5.2.2.2.
1.1.5.2.4 Actions at the incoming international gateway exchange
1.1.5.2.4.1 Normal operationSee 1.1.5.2.2.1.
1.1.5.2.4.2 Exceptional procedures
See 1.1.5.2.2.2.

B-IF3.51-01-TS3

1.1.5.2.5 Actions at the destination local exchange
1.1.5.2.5.1 Normal operation
The information which is generated as described in 1.1.5.2.1.1 is passed to the access.
1.1.5.2.5.2

Exceptional procedures

1.1.5.2.5.2.1 Rejection of implicit service request
See 1.1.5.2.5.2.3.
1.1.5.2.5.2.2 Rejection of explicit service request
If service 1 is explicitly requested as essential and the network already has or has obtained knowledge
that the network itself or the called user cannot support it, a release message is sent with cause value
29, “facility rejected”, or cause value 69, “requested facility not implemented”, and the diagnostic
containing the user-to-user indicators parameter name.
If the network already has or has obtained the knowledge that the network itself or the called user
cannot support service 1 and it was explicitly requested as non-essential, a “service 1 not provided”
indication is returned in the user-to-user indicators parameter in the address complete, call progress,
answer, connect, or release messages.
If the network does not understand the explicit service 1 request or the terminating call control does
not indicate acceptance or rejection then none of the address complete, call progress, answer, connect
or release messages returned to the originating exchange shall include either a service 1 acceptance orrejection. This type of response will be taken as an implicit rejection of service 1.
The first backward message that contains the user-to-user information shall also contain theacceptance of the service unless an acceptance was sent in a preceding backward message; otherwise
the explicit service 1 shall be considered rejected.
1.1.5.2.5.2.3 Discard of user-to-user information
If for the implicit service 1 the network is unable to pass the user-to-user information in the initialaddress message, for example, because the network does not support the service, then the user-to-userindicators parameter is included in the first appropriate backward message, e.g. an address complete
message, with the network discard indicator coded “UUI discarded by the network”. However, thisindication cannot be guaranteed as a segmentation message carrying user-to-user information can bediscarded without any indication when peer-to-peer interworking with B-IF3.37 ISUP takes place. If
the network is unable to pass the user-to-user information parameter in any other message, no
indication is provided.
If for the explicit service 1 the network is unable to pass the user-to-user information in any message,
no indication is provided.
The user may not be able to interpret incoming user-to-user information. In such situations, the user
should discard this information without disrupting normal call handling. No specific signalling isprovided by the network to accommodate this situation.
1.1.6

Interaction with other supplementary services

1.1.6.1 DTMF Transmission
No impact on ISUP.
1.1.6.2 Handover
Any UUI and/or request for PHS-UUS in a handover request received from public CS-ISDN interface
protocol shall not be transferred by the initial address message.

4

B-IF3.51-01-TS

1.1.6.3 User scrambling
No impact on ISUP.
1.1.6.4 Subaddress
No impact on ISUP.
1.1.6.5 Calling User Identification Presentation (CUIP)
No impact on ISUP.
1.1.6.6 Calling User Identification Restriction (CUIR)
No impact on ISUP.
1.1.6.7 Call Forwarding
1.1.6.7.1 Call Forwarding on PS Busy (CFB)
If the forwarding user does not subscribe to service 1 or inhibits service 1 on forwarded calls, twocases exist:a)

If service 1 was explicitly requested as “essential”, the call is cleared. The cause is“facility rejected”.

b) If service 1 was implicitly requested or explicitly requested as “non-essential”, theforwarding exchange will not include the user-to-user information parameter in theinitial address message used to set up the forwarded leg of the call. Also, if the user-touser indicators parameter is included in the outgoing initial address message, service 1
will be indicated as “no information”.. The procedures specified in 1.1.5.2.5.2 will
ensure that the calling user is informed, if applicable, of the lack of user-to-user
signalling capability.
If the forwarding user subscribes to service 1 and does not inhibit it on forwarded calls, the forwarding
exchange will try to supply the service requested. This will be accomplished by requesting service 1 in
the outgoing initial address message using the same request information that was contained in theoriginal initial address message. If the attempt is successful, user-to-user information transfer will beavailable between the calling user and the forwarded-to user.
In the case where a user determined user busy condition exists, the user-to-user indicators and/or userto-user information are also delivered to the forwarding user when the call is offered.
1.1.6.7.2 Call Forwarding on No Reply (CFNRy)
The implicit or explicit request for service 1 is sent to the forwarding user. If the forwarding user does
not subscribe to service 1, inhibits service 1 on forwarded calls, or explicitly rejects an explicit
request, two cases exist:a)

If service 1 was explicitly requested as “essential”, the call is cleared. The cause is“facility rejected”.
b) If service 1 was implicitly requested or explicitly requested as “non-essential”, theforwarding exchange will not include the user-to-user information parameter in theinitial address message used to set up the forwarded leg of the call. Also, if the user-touser indicators parameter is included in the outgoing initial address message, service 1
will be indicated as “no information”.. The procedures specified in 1.1.5.2.5.2 will
ensure that the calling user is informed, if applicable, of the lack of user-to-user
signalling capability.
If the forwarding user subscribes to service 1, does not inhibit it on forwarded calls and does not
explicitly reject the request, the action is taken as described under Call Forwarding on PS Busy (see1.1.6.7.1).

B-IF3.51-01-TS5

1.1.6.7.3 Call Forwarding Unconditional (CFU)As Call Forwarding on PS Busy (see 1.1.6.7.1).
1.1.6.7.4 Call Forwarding on PS Not Reachable (CFNRc)
As Call Forwarding on PS Busy (see 1.1.6. 7.1).
1.1.6.8 Call Barring
1.1.6.8.1 Barring of All Outgoing Calls (BAOC)
No impact on ISUP. (When outgoing call is possible only under the conditions of BAOC, UUI and/or
request of PHS-UUS may be sent or received.)
1.1.6.8.2 Barring of Outgoing International Calls (BOIC)
No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich outgoing call is possible only under the conditions of BOIC.)
1.1.6.8.3 Barring of Outgoing International Calls Except Call to Home Country (BOIC-exHC)
No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich outgoing call is possible only under the conditions of BOIC-exHC.)
1.1.6.8.4 Barring of All Incoming Calls (BAIC)No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich incoming call is possible only under the conditions of BAIC.)
1.1.6.8.5 Barring of Incoming Calls on Roaming outside Home Country (BIC-roam)
No impact on ISUP.( UUI and/or request of PHS-UUS may be sent to or received from the party towhich incoming call is possible only under the conditions of BIC-roam..)
1.1.6.9 Roaming
Further study
1.1.6.10 PHS User-to-User Signalling (PHS-UUS)
1.1.6.10.1 PHS User-to-User Signalling, service 1 (PHS-UUS1)
Not applicable.
1.1.6.10.2 PHS User-to-User Signalling, service 2 (PHS-UUS2)
More than one PHS User-to-User Signalling supplementary service may be requested in the initialaddress message. For any service which is not requested in conjunction with an explicit request forservice 1, the corresponding indicator is set to “no information” in the user-to-user indicators
parameter.
If more than one PHS User-to-User Signalling supplementary service is requested, while at least one
service is requested as essential, and that service cannot be provided, then the call will be cleared with
an appropriate cause indication.
If no services were requested as “essential”, the user-to-user indicators parameter in the backward
direction will indicate independent acceptance or rejection of each service requested. When the userto-user indicators parameter is sent, if neither an acceptance nor a rejection indication is appropriate
for a particular service, that service will be indicated as “no information”.
1.1.6.10.3 PHS User-to-User Signalling, service 3 (PHS-UUS3)
As PHS User-to-User Signalling, service 2 (see 1.1.6.10.2). If service 3 is requested after call set-up,
the interaction as described under 1.3.6.10.1 is applicable.
1.1.7
Interaction with other networks
In the case of call control interworking from a network supporting the PHS User-to-User Signalling
service 1 to

6

B-IF3.51-01-TS

– a non-No. 7 network;– a No. 7 network, not ISUP;– a No. 7 network not supporting the service,
the ISDN exchange receiving an initial address message including an implicit or explicit service
request retains knowledge of this request and returns signalling information about the PHS User-toUser Signalling service as specified in Table 1-1.

TABLE 1-1/B-IF3.51
Service 1 rejection in case of interworking
Interworking network

Implicit request

Non-essential request

Essential request

Non-SS No. 7 network

ACM; interworkingind.:interw. encountered

ACM; UUI ind.:service 1 not provided

Rel #29 + diagnostics(Note 1)SS No. 7 network,
not ISUP

ACM; ISDN user partind.: ISUP not all theway

ACM; UUI ind.:service 1 not provided

Rel #29 + diagnostics(Note 1)SS No. 7 network notsupporting the service

ACM or CON; UUI
ind.: UUI discarded(Note 2)

ACM or CON; UUI
ind.: service 1 notprovided (Note 3)

Rel #29 + diagnostics(Notes 1 and 3)

NOTES
1
The diagnostics field contains the user-to-user indicators parameter name and length.
2
If the UUI in the IAM has been discarded, the user-to-user indicators parameter contains “UUI
discarded by the network”.
If it is detected that the originating exchange has performed segmentation by sending UUI in the
additional segment, and a subsequent exchange knows that the segmentation procedure is notsupported by the succeeding network, the latter exchange will code the user-to-user indicators
parameter as “UUI discarded by the network”.. This knowledge may be obtained by reception of a
confusion message indicating that the segmentation message has been discarded.
3
A transit or international gateway exchange may have to generate service rejection in case a
confusion message is received indicating that the user-to-user indicators requesting the service are notsupported by the succeeding network.
Two ISDN networks that interwork may have to retain knowledge of the service request until it isclear whether both can support the service.

1.1.8
Signalling flows
Figure 1-1 shows a successful use of PHS-UUS service 1 when implicitly requested in a point-to-point
configuration. Figure 1-2 shows a successful use of PHS-UUS service 1 when explicitly requested..
The following Notes apply to Figures 1-1 and 1-2:
NOTES
1 In cases where an ALERTING indication is carried by a call progress message, the userto-user indicators parameter and/or user-to-user information parameter may be transported
in the call progress message.
2 In cases where the called user is an automatic answering terminal, the user-to-userindicators parameter and/or user-to-user information parameter may be transported in aconnect message.

B-IF3.51-01-TS

7

Originating
Exchange

Originating
Public CS

Transit
Exchange

Terminating
Exchange

Terminating
Public CS

SETUP
(UUI)
CALL
PROCEEDING
FACILITY(*)
FACILITY(*)

IAM
(UUI)
IAM
(UUI)
$&0

SETUP
(UUI)
CALL
PROCEEDING$&0FACILITY(*)
FACILITY(*)

ALERTING(UUI’)
CONNECT(UUI’’)DISCONNECT(UUI’’’)CPG(UUI’)ANM(UUI’’)CPG(UUI’)ANM(UUI’’)

CONNECT(UUI’’)
CONNECTACKREL(UUI’’’)REL(UUI’’’)RELEASERELEASECOMPLETE

ALERTING(UUI’)

5/&

DISCONNECT(UUI’’’)RLC
RELEASERELEASECOMPLETE

óãý7KLVýPHVVDJHýLVýRQO\ýXVHGýIRUýDXWKHQWLFDWLRQýIRUý&6ýW\SHìýWKDWýLVýVSHFLILHGýLQý%ð1:ìïííï

),*85(ýìðìî%ð,)êïèì
PHS-UUS service 1 - Successful case
(implicit request)

8

B-IF3.51-01-TS

Originating
Public CS

Originating
Exchange

Transit
Exchange

Terminating
Exchange

Terminating
Public CS

SETUP(S1=re,UUI)CALLPROCEEDING
FACILITY(*)
FACILITY(*)

IAM(UUI ind.
[S1=re,S2=ni,S3=ni],
UUI)

IAM
(UUI ind.
[S1=re,S2=ni,S3=ni],
UUI)
$&0

SETUP
(S1=re,UUI)CALLPROCEEDING$&0FACILITY(*)
CPG
CPG(UUI ind.
(UUI ind.
[S1=p,S2=ni,S3=ni],[S1=p,S2=ni,S3=ni],
UUI’)
UUI’)
ALERTING(S1=p,UUI’)CONNECT(UUI’’)DISCONNECT(UUI’’’)ANM(UUI’’)ANM(UUI’’)

FACILITY(*)
ALERTING(S1=p,UUI’)CONNECT(UUI’’)

CONNECTACKREL(UUI’’’)REL(UUI’’’)RELEASEDISCONNECT(UUI’’’)RLC
RELEASECOMPLETE

RLC

RELEASERELEASECOMPLETE

óãý7KLVýPHVVDJHýLVýRQO\ýXVHGýIRUýDXWKHQWLFDWLRQýIRUý&6ýW\SHìýWKDWýLVýVSHFLILHGýLQý%ð1:ìïííï

),*85(ýìðìî%ð,)êïèì
PHS-UUS service 1 - Successful case
(explicit request)

B-IF3.51-01-TS

9

Abbreviation
ni
rne
re
p
np
AbbreviationUUI
UUI ind.
Abbreviation
ACM
ANM
IAM
REL
RLC

User-to-user indicator values
No information
Requested, non-essential
Requested, essential
Provided
Not provided
Parameter nameUser-to-user information
User-to-user indicators
Message name
Address complete
AnswerInitial address
Release
Release complete

The messages shown with dashed lines are not part of the ISDN user part protocol and are for
information only. For detailed information on the access protocol user-to-user procedures the ISDN
access protocol PHS MoU Specifications should be examined.
1.1.9
Parameter values (timers)
None identified.
1.1.10 Dynamic description
No dynamic description (SDLs) is included.
1.2

PHS User-to-User Signalling service 2

1.2.1
DefinitionSee 1.1.1.
1.2.2

Description

1.2.2.1 General description
PHS User-to-User Signalling service 2 is used to exchange information between two users as
described in PHS MoU Specification B-SV2.70 (stage 1). The functional description (stage 2) for thisservice can be found in PHS MoU Specifictaion B-IF0.51. The stage3 PS-public CS interface protocol
description is given in PHS MoU Specification B-IF1.51.The stage 3 public CS-ISDN interface
protocol description is given in PHS MoU Specification B-IF2.51. This clause is specific to Signalling
System No. 7 and use is made of the ISDN user part protocol defined in PHS MoU spefications BIF3.31 to 3.34 and ITU-T Recommendation Q.730. Service 2 allows the users to communicate bytransferring up to two user-to-user information messages in each direction during the call set-up
phase. Up to 128 octets of user information may be transferred in each message.. The 128 octets do
not include the user-to-user information parameter name, the protocol control indicator or the length
octets.
As a network option, user-to-user information may be delivered to the called user after the call is
answered to accommodate situations where the information was sent at approximately the same timeas the call was answered.

10

B-IF3.51-01-TS

1.2.2.2 Specific terminology
See 1.1.2.2.
1.2.2.3 Qualification on the applicability to telecommunication services
See PHS MoU Specification B-SV2.70.
1.2.2.4 State definitions
No specific state definitions are required.
1.2.3

Operational requirements

1.2.3.1 Provision/withdrawal
See PHS MoU Specification B-SV2.70.
1.2.3.2 Requirements on the originating network side
Not applicable.
1.2.3.3 Requirements in the network
No specific requirements are needed in the network.
1.2.3.4 Requirements on the terminating network side
Not applicable.
1.2.4
Coding requirements
The request for service 2 is carried in the user-to-user indicators parameter in the initial address
message. User-to-user information is carried in the user-to-user information parameter in the user-touser information message.
The indication of acceptance or rejection of service 2 is carried in the user-to-user indicators
parameter in an address complete or call progress message.
1.2.5

Signalling requirements

1.2.5.1 Activation/deactivation/registration
PHS-UUS service 2 must be requested by the calling user at call set-up if UUI transfer is desired ineither direction.
Once a UUS service is activated (see Note), the network will accept UUI in both directions according
to the subscription of the calling user.
NOTE – Activation means request of PHS-UUS. Invocation means submission of UUI.
1.2.5.2 Invocation and operation
1.2.5.2.1 Actions at the originating local exchange
1.2.5.2.1.1

Normal operation

1.2.5.2.1.1.1 Service request
Service 2 is explicitly requested in an initial address message. As an option at call set-up, the callinguser may be able to specify whether the request for service 2 is essential or non-essential for the call(i.e. whether the call should be completed or not if user-to-user information cannot be passed).
Procedures for call set-up are as described in 2/B-IF3.34, with the following changes:–

On call set-up, the initial address message will contain the user-to-user indicators
parameter with service 2 indicated as “requested, essential” or “requested, not essential”,
as appropriate.

B-IF3.51-01-TS

11

–

–

For an essential request the ISUP preference indicator will be coded “ISUP required”.
The service request will be received from call control and will be passed to call control
at the destination exchange.
If the network and the called user can support the transfer of user-to-user information, aservice 2 acceptance will be returned to the originating exchange in an address complete
or call progress message with the indication “service 2 provided” in the user-to-userindicators parameter. This explicit indication shall be forwarded to the call control at theoriginating exchange.

1.2.5.2.1.1.2 Transfer of user-to-user information
Once acceptance of service 2 has been transmitted across the network, both of the involved users cantransfer user-to-user information between themselves. Within the network the user-to-user information
parameter will be carried in a user-to-user information message. The network provides for the transferof these messages from the calling to the called side and vice versa.
If a MORE DATA information element is received from public CS-ISDN interface protocol in a
USER INFO message, this information is carried in the access transport parameter associated with thecorresponding user-to-user information message for delivery at the destination access.
If service 2 is provided, no more than two user-to-user information messages carrying user-to-user
information parameters may be transmitted in each direction during the call set-up phase. If more than
two messages are received during call set-up, the additional messages are discarded. If only service 2
has been requested, one of the messages may also be received and passed after the answer state has
been reached.
1.2.5.2.1.2 Exceptional procedures
The originating exchange shall be able to interpret a rejection indication generated by any succeedingexchange and act accordingly (see 1.2.5.2.5.2).
1.2.5.2.2 Actions at the transit exchange
1.2.5.2.2.1 Normal operation
The information which is generated as described in 1.2.5.2.1.1 is passed unchanged.
1.2.5.2.2.2 Exceptional procedures
The information which is generated as described in 1.2.5.2.5.2 is passed unchanged. Rejection of aservice request (see 1.2.5.2.5.2) can also take place in the transit exchange.
1.2.5.2.3 Actions at the outgoing international gateway exchange
1.2.5.2.3.1 Normal operationSee 1.2.5.2.2.1.
1.2.5.2.3.2 Exceptional procedures
See 1.2.5.2.2.2.
1.2.5.2.4 Actions at the incoming international gateway exchange
1.2.5.2.4.1 Normal operationSee 1.2.5.2.2.1.
1.2.5.2.4.2 Exceptional procedures
See 1.2.5.2.2.2.

12

B-IF3.51-01-TS

1.2.5.2.5 Actions at the destination local exchange
1.2.5.2.5.1 Normal operation
The information which is generated as described in 1.2.5.2.1.1 is passed to the access.
1.2.5.2.5.2

Exceptional procedures

1.2.5.2.5.2.1 Rejection of service request
If the network already has or has obtained knowledge that the network itself or the called user cannot
support service 2, and service 2 was requested with a non-essential indication, a service 2 rejection
indication is returned in the address complete or call progress messages with the indication “service 2
not provided” in the user-to-user indicators parameter.
If service 2 was requested as essential and the network already has or has obtained knowledge that the
network itself or the called user cannot support it, a release message is sent with cause value 29,“facility rejected”, cause value 69, “requested facility not implemented”, and the diagnostic containing
the user-to-user indicators parameter name.
If the network does not understand the service 2 request or the terminating call control does notindicate acceptance or rejection, then the address complete or call progress messages returned to theoriginating exchange shall not include either a service 2 acceptance or rejection. This type of response
will be taken as an implicit rejection of service 2.
1.2.6

Interaction with other supplementary services

1.2.6.1 DTMF Transmission
No impact on ISUP.
1.2.6.2 Handover
Any request for PHS-UUS in a handover request received from public CS-ISDN interface protocol
shall not be transferred by the initial address message.
1.2.6.3 User scrambling
No impact on ISUP.
1.2.6.4 Subaddress
No impact on ISUP.
1.2.6.5 Calling User Identification Presentation (CUIP)
No impact on ISUP.
1.2.6.6 Calling User Identification Restriction (CUIR)
No impact on ISUP.

1.2.6.7 Call Forwarding
1.2.6.7.1 Call Forwarding on PS Busy (CFB)
If the forwarding user does not subscribe to service 2 or inhibits service 2 on forwarded calls, twocases exist:a)

If service 2 was explicitly requested as “essential”, the call is cleared. The cause is“facility rejected”.
b) If service 2 was explicitly requested as “non-essential”, the forwarding exchange will
include the user-to-user indicators parameter in the outgoing initial address message
used to set up the forwarded leg of the call with service 2 indicated as “no information”..

B-IF3.51-01-TS

13

Procedures specified in 1.2.5.2.5.2 will ensure that the calling user is informed, if
applicable, of the lack of user-to-user signalling capability.
If the forwarding user subscribes to service 2 and does not inhibit it on forwarded calls, the forwarding
exchange will try to supply the service requested. This will be accomplished by requesting service 2 inthe outgoing initial address message using the same request information that was contained in theoriginal initial address message. If the attempt is successful, user-to-user information transfer will beavailable between the calling user and the forwarded-to user.
In the case where a user determined user busy condition exists, the user-to-user indicators are alsodelivered to the forwarding user when the call is offered.
1.2.6.7.2 Call Forwarding on No Reply (CFNRy)
Service 2 is not extended to the forwarded-to user in the case of call forwarding no reply, but the userto-user indicators are delivered to the forwarding user when the call is offered.
If service 2 was explicitly requested as “essential”, the call is cleared. The cause is “facility rejected”.
If service 2 was explicitly requested as “non-essential”, the forwarding exchange will include the userto-user indicators parameter in the outgoing initial address message used to set up the forwarded leg ofthe call with service 2 indicated as “no information”.. Procedures specified in 1.2.5.2.5.2 will ensurethat the calling user is informed, if applicable, of the lack of user-to-user signalling capability.
1.2.6.7.3 Call Forwarding Unconditional (CFU)As Call Forwarding on PS Busy (see 1.2.6.7.1).

1.2.6.7.4 Call Forwarding on PS Not Reachable (CFNRc)
As Call Forwarding on PS Busy (see 1.2.6. 7.1).
1.2.6.8 Call Barring
1.2.6.8.1 Barring of All Outgoing Calls (BAOC)
No impact on ISUP. (When outgoing call is possible only under the conditions of BAOC, UUI and/or
request of PHS-UUS may be sent or received.)
1.2.6.8.2 Barring of Outgoing International Calls (BOIC)
No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich outgoing call is possible only under the conditions of BOIC.)
1.2.6.8.3 Barring of Outgoing International Calls Except Call to Home Country (BOIC-exHC)
No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich outgoing call is possible only under the conditions of BOIC-exHC.)
1.2.6.8.4 Barring of All Incoming Calls (BAIC)No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich incoming call is possible only under the conditions of BAIC.)
1.2.6.8.5 Barring of Incoming Calls on Roaming outside Home Country (BIC-roam)
No impact on ISUP.( UUI and/or request of PHS-UUS may be sent to or received from the party towhich incoming call is possible only under the conditions of BIC-roam..)
1.2.6.9 Roaming

14

B-IF3.51-01-TS

Further study
1.2.6.10 PHS User-to-User Signalling (PHS-UUS)
1.2.6.10.1 PHS User-to-User Signalling, service 1 (PHS-UUS1)
More than one PHS User-to-User Signalling supplementary service may be requested in the initialaddress message. For any service which is not explicitly requested in conjunction with a request forservice 2, the corresponding indicator is set to “no information” in the user-to-user indicators
parameter.
If more than one PHS User-to-User Signalling supplementary service is requested, while at least one
service is requested as essential, and that service cannot be provided, then the call will be cleared with
an appropriate cause indication.
If no services were requested as “essential”, the user-to-user indicators parameter in the backward
direction will indicate independent acceptance or rejection of each service requested. When the userto-user indicators parameter is sent, if neither an acceptance nor a rejection indication is appropriate
for a particular service, that service will be indicated as “no information”..
1.2.6.10.2 PHS User-to-User Signalling, service 2 (PHS-UUS2)
Not applicable.
1.2.6.10.3 PHS User-to-User Signalling, service 3 (PHS-UUS3)
As PHS User-to-User Signalling, service 1 (see 1.2.6.10.1). If service 3 is requested after call set-up,
the interaction as described under 1.3.6.10.1 is applicable.
1.2.7
Interaction with other networks
In the case of call control interworking from a network supporting the PHS User-to-User Signalling
service 2 to
– a non-No. 7 network;– a No. 7 network, not ISUP;– a No. 7 network not supporting the service,
the ISDN exchange receiving an initial address message including an explicit service request retains
knowledge of this request and returns signalling information about the PHS User-to-User Signalling
service as specified in Table 1-2.

B-IF3.51-01-TS

15

TABLE 1-2/B-IF3.51
Service 2 rejection in case of interworking
Interworking
network

Non-essential
requestEssential request

Non-SS No. 7
network

ACM; UUI ind.:service 2 not provided

Rel #29 + diagnostics(Note 1)SS No. 7 network, notISUP

ACM;UUI ind.:service 2 not provided

Rel #29 + diagnostics(Note 1)SS No. 7 network notsupporting the service

ACM or CON; UUI ind.:service 2 not provided (Note 2)

Rel #29 + diagnostics(Notes 1 and 2)

NOTES
1
The diagnostics field contains the user-to-user indicators parameter name and length.
2
A transit or international gateway exchange may have to generate service rejection incase a confusion message is received indicating that the user-to-user indicators requesting theservice are not supported by the succeeding network.
Two ISDN networks that interwork may have to retain knowledge of the service request until
it is clear whether both can support the service.

1.2.8
Signalling flows
Figure 1-3 and 1-4 shows a successful use of PHS-UUS service 2 when requested.

16

B-IF3.51-01-TS

Originating
Public CS

Originating
Exchange

Transit
Exchange

Terminating
Exchange

Terminating
Public CS

SETUP(S2=rne)CALL
PROCEEDING
FACILITY(*)
FACILITY(*)

IAM(UUI ind.
[S1=ni,S2=rne,S3=ni])

IAM(UUI ind.
[S1=ni,S2=rne,S3=ni])
SETUP(S2=rne)$&0
CALL
PROCEEDING$&0FACILITY(*)
FACILITY(*)
CPG
CPG

ALERTING(S2=p)USER
INFORMATION(UUI ind.
[S1=ni,S2=p,S3=ni])

USR(UUI ind.
[S1=ni,S2=p,S3=ni])

USR

ALERTING(S2=p)USER
INFORMATIONUSER
INFORMATIONUSER
INFORMATION

USR

USR
ANM

CONNECTANM
CONNECT

CONNECT
ACK

óãý7KLVýPHVVDJHýLVýRQO\ýXVHGýIRUýDXWKHQWLFDWLRQýIRUý&6ýW\SHìýWKDWýLVýVSHFLILHGýLQý%ð1:ìïííï

FIGURE 1-3/B-IF3.51
PHS-UUS service 2 - Successful caseC

(PHS-UUS provided)

B-IF3.51-01-TS

17

CM
Originating
Public CS

Originating
Exchange

Transit
Exchange

Terminating
Exchange

Terminating
Public CS

SETUP(S2=rne)CALL
PROCEEDING
FACILITY(*)
FACILITY(*)

IAM(UUI ind.
[S1=ni,S2=rne,S3=ni])

IAM(UUI ind.
[S1=ni,S2=rne,S3=ni])
SETUP(S2=rne)
$&0

$&0

CALL
PROCEEDING
FACILITY(*)

FACILITY(*)
CPG

ALERTING(S2=np)(UUI ind.
[S1=ni,S2=np,S3=ni])CPG(UUI ind.
[S1=ni,S2=np,S3=ni])

ANM

ALERTING(S2=np)

CONNECTANM
CONNECT

CONNECT
ACK

óãý7KLVýPHVVDJHýLVýRQO\ýXVHGýIRUýDXWKHQWLFDWLRQýIRUý&6ýW\SHìýWKDWýLVýVSHFLILHGýLQý%ð1:ìïííï

FIGURE 1-4/B-IF3.51
PHS-UUS service 2 - Successful case(PHS-UUS not provided)18

B-IF3.51-01-TS

The following Notes apply to Figures 1-3 and 1-4:
NOTES
1 In cases where an ALERTING indication is carried by a call progress message, theuser-to-user indicators parameter may be transported in the call progress message.
2 In cases where the called user is an automatic answering terminal, the user-to-userindicators parameter may be transported in a connect message.
The following abbreviations are used in Figures 1-3 and 1-4:
Abbreviation
ni
rne
re
p
np

User-to-user indicator values
No information
Requested, non-essential
Requested, essential
Provided
Not provided

AbbreviationUUI
UUI ind.

Parameter nameUser-to-user information
User-to-user indicators

Abbreviation
ACM
ANM
IAM
REL
RLC
USR

Message name
Address complete
AnswerInitial address
Release
Release complete
User-to-user information

The messages shown with dashed lines are not part of the ISDN user part protocol and are for
information only. For detailed information on the access protocol user-to-user procedures the ISDN
access protocol PHS MoU Specifications should be examined.
1.2.9
Parameter values (timers)
None identified.
1.2.10 Dynamic description
No dynamic description (SDLs) is included.

B-IF3.51-01-TS

19

1.3

PHS User-to-User Signalling service 3

1.3.1
DefinitionSee 1.1.1.
1.3.2

Description

1.3.2.1 General description
PHS User-to-User Signalling service 3 is used to exchange information between two users as
described in PHS MoU Specification B-SV2.70 (stage 1). The functional description (stage 2) for thisservice can be found in PHS MoU Specification B-IF0.51. The stage 3 PS-public CS interface
protocol description is given in PHS MoU Speficication B-IF1.51.The stage 3 public CS-ISDN
interface protocol description is given in PHS MoU Specifications B-IF2.51.. This clause is specific to
Signalling System No. 7 and use is made of the ISDN user part defined in PHS MoU Specifications
B-IF3.31 to 3.34 and ITU-T Recommendation Q.730. Use is also made of SCCP class 2 protocols
defined in PHS MoU Specifications B-IF4.11 to 4.14 and ITU-T Recommendation Q.730. However,the procedures for the application of SCCP class 2 protocols for PHS User-to-User Signalling service
3 are for further study. Service 3 allows users to communicate by transferring user-to-user information
messages in each direction during the active phase of the call. Up to 128 octets of user information
may be transferred in each message. The 128 octets do not include the user-to-user information
parameter name, the protocol control indicator or the length octets.
Service 3 allows the service to be requested either during call set-up or after call set-up. However,service 3 should not be requested after call set-up if it has been rejected during the call set-up phase.
1.3.2.2 Specific terminology
See 1.1.2.2.
1.3.2.3 Qualification on the applicability to telecommunication services
See PHS MoU Specification B-SV2.70.
1.3.2.4 State definitions
No specific state definitions are required.
1.3.3

Operational requirements

1.3.3.1 Provision/withdrawal
See PHS MoU Specification B-SV2.70.
1.3.3.2 Requirements on the originating network side
Not applicable.
1.3.3.3 Requirements in the network
No specific requirements are needed in the network.
1.3.3.4 Requirements on the terminating network side
Not applicable.
1.3.4
Coding requirements
The request for service 3 during call set-up is carried in the user-to-user indicators parameter in theinitial address message. User-to-user information is carried in the user-to-user information parameterin the user-to-user information message.
The indication of acceptance or rejection of service 3 during call set-up is carried in the user-to-userindicators parameter in the answer or connect messages.

20

B-IF3.51-01-TS

The request for service 3 after call set-up is carried in the facility request message. The acceptance of
this request is carried in the facility accepted message; the rejection in the facility reject message. The
facility indicator parameter (set to “user-to-user service”) and the user-to-user indicators parameter(containing the relevant service 3 information) are included in each of these messages.
1.3.5

Signalling requirements

1.3.5.1 Activation/deactivation/registration
PHS-UUS service 3 may be requested by the calling user at call set-up or either the calling or calleduser after call set-up if UUI transfer is desired in either direction.
Once a PHS-UUS service is activated (see Note), the network will accept UUI in both directions
according to the subscription of the requesting user.
NOTE – Activation means request of PHS-UUS. Invocation means submission of UUI.
1.3.5.2 Invocation and operation
1.3.5.2.1 Actions at the originating local exchange
1.3.5.2.1.1

Normal operation

1.3.5.2.1.1.1 Service request during call set-up
Service 3 is explicitly requested in an initial address message. As an option at call set-up, the callinguser may be able to specify whether the request for service 3 is essential or non-essential for the call(i.e. whether the call should be completed or not if user-to-user information cannot be passed).
Procedures for call set-up are as described in 2/B-IF3.04, with the following changes:–

On call set-up, the initial address message will contain the user-to-user indicators
parameter with service 3 indicated as “requested, essential” or “requested, not essential”,
as appropriate. For an essential request the ISUP preference indicator will be coded“ISUP required”.. The service request will be received from call control and will bepassed to the call control at the destination exchange.

–

When service 3 has been requested in the initial address message, any acceptance orrejection is returned in an answer or connect message in the user-to-user indicators
parameter.
If the network and called user can support the transfer of user-to-user information, aservice 3 acceptance will be returned to the originating exchange in an answer orconnect message with the indication “service 3 provided” in the user-to-user indicators
parameter. This explicit indication shall be forwarded to the call control at theoriginating exchange.

–

1.3.5.2.1.1.2 Service request after call set-up
After call set-up has been completed either the calling or called user may request to transfer service 3
information. On reception of the request from call control the ISDN user part sends a facility request
message containing the facility indicator parameter indicating “user-to-user service” and a user-touser indicators parameter with service 3 indicated as “requested, not essential” to the distant local
exchange using the appropriate transport method. On receipt of the facility request message at the
distant exchange call control will be notified which will then notify the remote user. If the user wishes
to support service 3 during the active phase, a service 3 acceptance will be returned to call control. On
notification of the acceptance by call control the ISDN user part will generate a facility accepted
message with the indication “service 3 provided” in the user-to-user indicators parameter. On receiptof the message this explicit acceptance indication shall be forwarded to call control which will thennotify the requesting user.

B-IF3.51-01-TS

21

1.3.5.2.1.1.3 Transfer of user-to-user information
Once acceptance of service 3 has been transmitted across the network, both of the involved users cantransfer user-to-user information between themselves. Within the network the user-to-user information
parameter will be carried in a user-to-user information message. The network provides for the transferof these messages from the calling to the called side and vice versa.
If a MORE DATA information element is received from public CS-ISDN interface protocol in a
USER INFO message, this information is carried in the access transport parameter associated with thecorresponding user-to-user information message for delivery at the destination access.
1.3.5.2.1.1.4 Flow control
The exchange of user-to-user information is limited by flow control procedures provided on the accessby either the user or network. The need for inter-exchange flow control procedures by the ISDN userpart for PHS User-to-User Signalling should be evaluated.
1.3.5.2.1.2 Exceptional procedures
The originating exchange shall be able to interpret a rejection indication generated by any succeedingexchange and act accordingly (see 1.3.5.2.5.2).
1.3.5.2.2 Actions at the transit exchange
1.3.5.2.2.1 Normal operation
The information which is generated as described in 1.3.5.2.1.1 is passed unchanged.
1.3.5.2.2.2 Exceptional procedures
The information which is generated as described in 1.3.5.2.5.2 is passed unchanged. Rejection of aservice request (see 1.3.5.2.5.2) can also take place in the transit exchange.
1.3.5.2.3 Actions at the outgoing international gateway exchange
1.3.5.2.3.1 Normal operationSee 1.3.5.2.2.1.
1.3.5.2.3.2 Exceptional procedures
See 1.3.5.2.2.2.
1.3.5.2.4 Actions at the incoming international gateway exchange
1.3.5.2.4.1 Normal operationSee 1.3.5.2.2.1.
1.3.5.2.4.2 Exceptional procedures
See 1.3.5.2.2.2.
1.3.5.2.5 Actions at the destination local exchange
1.3.5.2.5.1 Normal operation
The information which is generated as described in 1.3.5.2.1.1 is passed to the access.
1.3.5.2.5.2

Exceptional procedures

1.3.5.2.5.2.1 Rejection of service request during call set-up
If the network already has or has obtained knowledge that the network itself or the called user cannot
support service 3, and it was requested with a non-essential indication, a service 3 rejection indicationis returned in the answer or connect messages with the indication “service 3 not provided” in the userto-user indicator parameter.

22

B-IF3.51-01-TS

If the service 3 request is indicated as essential and the network already has or has obtained
knowledge that the network itself or the called user cannot support it, a release message is sent withcause value 29, “facility rejected” or cause value 29, “requested facility not implemented” and the
diagnostic containing the user-to-user indicators parameter name.
If the network does not understand the service 3 request or the terminating call control does notindicate acceptance or rejection then any message returned to the originating exchange shall notinclude either a service 3 acceptance or rejection. This type of response will be taken as an implicit
rejection of service 3.
1.3.5.2.5.2.2 Rejection of service requested after call set-up
The network may not understand the service 3 request due to inconsistent or unrecognized informationin the facility request message. If this occurs or the remote call control does not indicate acceptance orrejection then no message is returned. This response shall be taken as an implicit rejection of service
3. This may also occur if interworking takes place in which case a facility accepted or facility reject
message may not always be returned.
It is also possible that the facility accepted or facility reject messages cannot be correctly interpreted
due to inconsistent or unrecognized information. The network shall discard these messages in thiscase. Only the information pertaining to service 3 has to be interpreted in the facility request, facility
accepted, and facility reject messages. Information related to services 1 and 2 shall be ignored.
If the network or remote user cannot support service 3, a service 3 rejection indication is returned in
the facility reject message in the user-to-user indicator parameter with the indication “service 3 notprovided”.
1.3.6

Interaction with other supplementary services

1.3.6.1 DTMF Transmission
No impact on ISUP.
1.3.6.2 Handover
Any request for PHS-UUS in a handover request received from Public CS-ISDN interface protocol
shall not be transferred by the initial address message.
1.3.6.3 User scrambling
No impact on ISUP.
1.3.6.4 Subaddress
No impact on ISUP.
1.3.6.5 Calling User Identification Presentation (CUIP)
No impact on ISUP.
1.3.6.6 Calling User Identification Restriction (CUIR)
No impact on ISUP.
1.3.6.7 Call Forwarding
1.3.6.7.1
Call Forwarding on PS Busy (CFB)
If the forwarding user does not subscribe to service 3 or inhibits service 3 on forwarded calls, twocases exist:

B-IF3.51-01-TS

23

a)

If service 3 was explicitly requested as “essential”, the call is cleared. The cause is“facility rejected”.

b) If service 3 was explicitly requested as “non-essential”, the forwarding exchange will
include the user-to-user indicators parameter in the outgoing initial address message
used to set up the forwarded leg of the call with service 3 indicated as “no information”..
Procedures specified in 1.3.5.2.5.2 will ensure that the calling user is informed, if
applicable, of the lack of user-to-user signalling capability.
If the forwarding user subscribes to service 3 and does not inhibit it on forwarded calls, the forwarding
exchange will try to supply the service requested. This will be accomplished by requesting service 3 inthe outgoing initial address message using the same request information that was contained in theoriginal initial address message. If the attempt is successful, user-to-user signalling informationtransfer will be available between the calling user and the forwarded-to user.
In the case where a user determined user busy condition exists, the user-to-user indicators are alsodelivered to the forwarding user when the call is offered.
There is no interaction between call forwarding and a request for service 3 during the active phase of
the call.
1.3.6.7.2 Call Forwarding on No Reply (CFNRy)As Call Forwarding on PS Busy (see 1.3.6.7..1) with one exception: the user-to-user indicators aredelivered to the forwarding user when the call is offered.
1.3.6.7.3 Call Forwarding Unconditional (CFU)As Call Forwarding on PS Busy (see 1.3.6.7.1).
1.3.6.7.4 Call Forwarding on PS Not Reachable (CFNRc)
As Call Forwarding on PS Busy (see 1.3.6. 7.1).

1.3.6.8 Call Barring
1.3.6.8.1 Barring of All Outgoing Calls (BAOC)
No impact on ISUP. (When outgoing call is possible only under the conditions of BAOC, UUI and/or
request of PHS-UUS may be sent or received.)
1.3.6.8.2 Barring of Outgoing International Calls (BOIC)
No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich outgoing call is possible only under the conditions of BOIC.)
1.3.6.8.3 Barring of Outgoing International Calls Except Call to Home Country (BOIC-exHC)
No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich outgoing call is possible only under the conditions of BOIC-exHC.)
1.3.6.8.4 Barring of All Incoming Calls (BAIC)No impact on ISUP.(UUI and/or request of PHS-UUS may be sent to or received from the party towhich incoming call is possible only under the conditions of BAIC.)
1.3.6.8.5 Barring of Incoming Calls on Roaming outside Home Country (BIC-roam)
No impact on ISUP.( UUI and/or request of PHS-UUS may be sent to or received from the party towhich incoming call is possible only under the conditions of BIC-roam..)
1.3.6.9 Roaming

24

B-IF3.51-01-TS

Further study
1.3.6.10 PHS User-to-User Signalling (PHS-UUS)
1.3.6.10.1 PHS User-to-User Signalling, service 1 (PHS-UUS1)
More than one PHS User-to-User Signalling supplementary service may be requested in the initialaddress message. For any service which is not explicitly requested in conjunction with a request forservice 3, the corresponding indicator is set to “no information” in the user-to-user indicators
parameter.
If more than one PHS User-to-User Signalling supplementary service is requested, while at least one
service is requested as essential, and that service cannot be provided, then the call will be cleared with
an appropriate cause indication.
If no services were requested as “essential”, the user-to-user indicators parameter in the backward
direction will indicate independent acceptance or rejection of each service requested. When the userto-user indicators parameter is sent, if neither an acceptance nor a rejection indication is appropriate
for a particular service, that service will be indicated as “no information”.
If service 3 is requested after call set-up, the indicators for service 1 and service 2 in the user-to-userindicators parameter in a facility request, facility accepted, or facility reject message will be set to “noinformation”.
1.3.6.10.2 PHS User-to-User Signalling, service 2 (PHS-UUS2)As PHS User-to-User Signalling, service 1 (see 1.3.6.10.1).
1.3.6.10.3 PHS User-to-User Signalling, service 3 (PHS-UUS3)
Not applicable.
1.3.7

Interaction with other networks

1.3.7.1 Service request during call set-up
In the case of call control interworking from a network supporting the PHS User-to-User Signalling
service 3 to
– a non-No. 7 network;– a No. 7 network, not ISUP;– a No. 7 network not supporting the service,
the ISDN exchange receiving an initial address message including an explicit service request retains
knowledge of this request and returns signalling information about the PHS User-to-User Signalling
service as specified in Table 1-3.

B-IF3.51-01-TS

25

TABLE 1-3/B-IF3.51
Service 3 rejection in case of interworking
Interworking
network
Non-SS No. 7 network
SS No. 7 network, not ISUP
SS No. 7 network notsupporting the service

Non-essential
requestACM; UUI ind.:service 3 not provided
ACM;UUI ind.:service 3 not provided
ACM or CON; UUI ind.:service 3 not provided (Note2)

Essential request
Rel #29 + diagnostics(Note 1)
Rel #29 + diagnostics(Note 1)
Rel #29 + diagnostics(Notes 1 and 2)

NOTES
1
The diagnostics field contains the user-to-user indicators parameter name and length.
2
A transit or international gateway exchange may have to generate service rejection in casea confusion message is received indicating that the user-to-user indicators requesting the service
are not supported by the succeeding network.
Two ISDN networks that interwork may have to retain knowledge of the service request until it
is clear whether both can support the service.

1.3.7.2 Service request after call set-up
The rejection of the service as described in 1.3.5.2.5.2.2 shall be applicable for the interworking cases
described in 1.3.7.1.
1.3.8
Signalling flows
Figure 1-5 and 1-6 shows a successful use of PHS User-to-User Signalling service 3 when requested
as non-essential during call set-up. Figure 1-7 shows a successful use of PHS User-to-User Signalling
service 3 when requested after call set-up.
The following Notes apply to Figures 1-5,1-6 and 1-7:
NOTES
1 In cases where an ALERTING indication is carried by a call progress message, the userto-user indicators parameter may be transported in the call progress message.
2 In cases where the called user is an automatic answering terminal, the user-to-userindicators parameter may be transported in a connect message.
The following abbreviations are used in Figures 1-5,1-6 and 1-7:

26

B-IF3.51-01-TS

Abbreviation
ni
rne
re
p
np

User-to-user indicator values
No information
Requested, non-essential
Requested, essential
Provided
Not provided

AbbreviationUUI
UUI ind.

Parameter nameUser-to-user information
User-to-user indicators

Abbreviation
ACM
ANM
FAA
FAR
IAM
REL
RLC
USR

Message name
Address complete
AnswerFacility accepted
Facility request
Initial address
Release
Release complete
User-to-user information

The messages shown with dashed lines are not part of the ISDN user part protocol and are for
information only. For detailed information on the access protocol user-to-user procedures the ISDN
access protocol PHS MoU Specifications should be examined.
1.3.9
Parameter values (timers)
None identified.
1.3.10 Dynamic description
No dynamic description (SDLs) is included.

B-IF3.51-01-TS

27

Originating
Public CS

Originating
Exchange

Transit
Exchange

Terminating
Exchange

Terminating
Public CS

SETUP(S3=rne)CALL
PROCEEDING
FACILITY(*)
FACILITY(*)

IAM(UUI ind.
[S1=ni,S2=ni,S3=rne])

IAM(UUI ind.
[S1=ni,S2=ni,S3=rne])
SETUP(S3=rne)
$&0

$&0

CALL
PROCEEDING
FACILITY(*)
FACILITY(*)

ALERTING

CONNECT(S3=p)CPG

ALERTINGANM(UUI ind.
[S1=ni,S2=ni,S3=p]

CONNECT(S3=p)CPG

ANM(UUI ind.
[S1=ni,S2=ni,S3=p]

CONNECTACKUSER
INFORMATION
USR

USR

USER
INFORMATIONUSER
INFORMATIONUSER
INFORMATION

USR

USR

óãý7KLVýPHVVDJHýLVýRQO\ýXVHGýIRUýDXWKHQWLFDWLRQýIRUý&6ýW\SHìýWKDWýLVýVSHFLILHGýLQý%ð1:ìïííï

FIGURE 1-5/B-IF3.51
PHS-UUS service 3 - Successful case(non-essential, provided)28

B-IF3.51-01-TS

Originating
Public CS

Originating
Exchange

Transit
Exchange

Terminating
Exchange

Terminating
Public CS

SETUP(S3=rne)CALL
PROCEEDING
FACILITY(*)
FACILITY(*)

IAM(UUI ind.
[S1=ni,S2=ni,S3=rne])

IAM(UUI ind.
[S1=ni,S2=ni,S3=rne])
SETUP(S3=rne)
$&0

$&0

CALL
PROCEEDING
FACILITY(*)

FACILITY(*)

CPG
ALERTING

CONNECT(S3=np)

ALERTING

CPG
ANM
ANM
(UUI ind.
[S1=ni,S2=ni,S3=np])(UUI ind.
[S1=ni,S2=ni,S3=np])

CONNECT(S3=np)
CONNECT
ACK

óãý7KLVýPHVVDJHýLVýRQO\ýXVHGýIRUýDXWKHQWLFDWLRQýIRUý&6ýW\SHìýWKDWýLVýVSHFLILHGýLQý%ð1:ìïííï

FIGURE 1-6/B-IF3.51
PHS-UUS service 3- Successful case(non-essential, not provided)

B-IF3.51-01-TS

29

Originating
Public CS

Originating
Exchange

Transit
Exchange

Terminating
Exchange

Terminating
Public CS

SETUP
CALL
PROCEEDING
FACILITY(*)
FACILITY(*)
IAM
IAM
SETUP
$&0
CALL
PROCEEDING$&0FACILITY(*)
FACILITY(*)

CPG
ALERTING

CPG
CONNECTANM

ANM
CONNECT
FACILITY(S3=rne)CONNECTACKFAR(UUI ind.
[S1=ni,S2=ni,S3=rne])

FAR(UUI ind.
[S1=ni,S2=ni,S3=rne])

FACILITY(S3=p)

ALERTINGFAR(UUI ind.
[S1=ni,S2=ni,S3=p])

FACILITY(S3=rne)FAR(UUI ind.
[S1=ni,S2=ni,S3=p])

FACILITY(S3=p)USR

USR
INFORMATIONUSRINFORMATION
USR

óãý7KLVýPHVVDJHýLVýRQO\ýXVHGýIRUýDXWKHQWLFDWLRQýIRUý&6ýW\SHìýWKDWýLVýVSHFLILHGýLQý%ð1:ìïííï

FIGURE 1-7/B-IF3.51
PHS-UUS service 3- Required after call is active(required to be non-essential)

30

B-IF3.51-01-TS