PHS MoU Document
B-IF2.51-02-TS
Title: Public Personal Handy-phone System : Public Cell Station - ISDN Interface- PHS-UUS Supplementary service -Version: 02
Date: July 14, 1999
PHS MoU Classification: Unrestricted
List of contents:<Summary>
1. Relations with international standards
2. Differences from ITU-T recommendation Q.957
3. References
4. Items for further study<Text>
1 PHS User-to-User Signalling (PHS-PHS-UUS)
1.1 Definition
1.2 Description
1.3 Operational requirements
1.4 Coding requirements
1.5 Signalling requirements
1.6 Interaction with other supplementary services
1.7 Interaction with other networks
1.8 signalling flows
1.9 Parameter values (timers)
1.10 Dynamic Description SDLs
Annex A Necessary Change in B-IF2.02

Number of pages: 27

Technical WG

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 Group 1999

PHS MoU Document

B-IF2.51-02-TS
VersionHistory of Revised Versions
Date
Outline01

July 31, 1998

Established

02

July 14, 1999

Changing the description of “object ID”

Note :A preliminary Technical Specifications or a technical explanatory document is published as aTechnical Report (TR).
This Technical Report (TR) is a preliminary Technical Specifications and will be published asa Technical specifications (TS) in the future when it is completed as a Technical Specifications(TS).

B-IF2.51-02-TS
Personal Handy-Phone System : Public Cell Station - ISDN Interface-PHS-UUS Supplementary Service-<Summary>

1. Relations with international standards
This specification specifies the public cell station - ISDN interface for PHS-UUS supplementary
services based on ITU-T Recommendation Q.957.1
2. Differences from ITU-T Recommendation Q.957.1
The differences between this specification and ITU-T Recommendation Q.957.1 are summarized in
the following table.

Table Summary-1/B-IF2.51 Differences from ITU-T Recommendation Q.957.1
Item1)Commonterms2)Messages3)Callcontention

Differences(1)“user” is changed to “public cell station”
and “network” to “ISDN.”
Note - “user” is not replaced with “public
CS“ when “user” is used in the context
related to subscription.
(2) “User-to-User Signalling” is changed to“PHS User-to-User Signalling”(3)“ITU-T Recommendation Q.931” and“ITU-T Recommendation Q.932” ischanged to “PHS MoU specification
B-IF2.02” and “PHS MoU
specification B-IF 2.01”.
(4)“service 1, 2 and 3” is changed to “PHSUUS service 1, 2 and 3”.
SETUP ACKNOWLEDGE message is not
used.

Reasons(1)This change makes clear what“user” and “network” mean.
(2)This change conforms to BSV2.70.
(3)“Q.931” and “Q.932” in ITU-T
Recommendation correspond to“B-IF 2.02” and “B-IF 2.01” in
PHS MoU specification.
(4)This change makes clear that
“service 1, 2 and 3” are “PHSUUS service 1, 2 and 3”.

SETUP ACKNOWLEDGE
message is not specified in MoU
specification B-IF 2.02
Procedures related to call contention are Point-to-multipoint arrangement isdeleted.
not specified in B-SV2.70.
(Point-to-multipoint is a situation
where multiple responses to an
incoming call cannot occur.)

B-IF2.51-02-TSõìô4)Interaction
with othersupplementary
services5)Interaction
with othernetworks
6)Signallingflow7)Facility
information
element in
RELEASECOMPLETE
message3.

All descriptions are revisedThis change conforms tointeraction with supplementary
services specified in B-SV2.70

All descriptions are revised.
Inter action with other PHS network andinteraction with ISDN network is described.
All descriptions are revised. It is changed as“In addition to basic control according to
Q.931, the signalling flow described in BIF0.51 is added for your reference.”
Facility information element in RELEASECOMPLETE message is added in thesection “1.4.1 messages.”

This change conforms tointeraction with other networks
specified in B-SV2.70
This change makes it easier tounderstand the signalling flow.

This change conforms to thecontent of the section “1.5.2
Invocation and operation”, i.e. theacceptance or rejection of PHSUUS request can be included in
RELEASE COMPLETE message.

References

ITU-T Recommendation Q.957.1
PHS MoU Specification B-IF2.01,B-IF2.02, B-SV2.70
4.

Items for Further Study(1) ASN.1 description
ASN.1 description of the operation required for the PHS-UUS supplementary service is for further
study. It is necessary to study object identifier of the operation.

õëô

B-IF2.51-02-TS

B-IF2.51-02TS
Public Personal Handy-Phone System:
Interface between Public Cell Station and ISDN-based PHS Switching Center-PHS User-to-User Signalling (PHS-UUS)-

ContentsPage
1 •PHS User-to-User Signalling (PHS-UUS) .............................................................. 1
1.1 Definition .............................................................................................................. 1
1.2 Description ............................................................................................................ 1
1.3 Operational requirements ...................................................................................... 2
1.4 Coding Requirements ............................................................................................ 4
1.5 Signalling requirements ...................................................................................... 12
1.6 Interaction with other supplementary services .................................................... 22
1.7 Interactions with other networks ......................................................................... 25
1.8 Signalling flow .................................................................................................... 26
1.9 Parameter values (timers) .................................................................................... 27
1.10 Dynamic description SDLs ............................................................................... 27

B-IF2.51-02-TS i

1. PHS User-to-User Signalling (PHS-UUS)
1.1 Definition
The PHS User-to-User Signalling (PHS-UUS) supplementary service allows an PHS public CS to
send/receive a limited amount of information to/from another PHS user over the communication
channel in association with a call to the other PHS public CS.
1.2 Description
1.2.1 General description
The PHS-UUS supplementary services provide a means of communication between two users byusing as a basis the layer 3 protocol defined in 5/B-IF2.02 [1]. User-user signalling is used to
exchange information between two users to provide the services described in the Stage 1 Service
Description. The exchange of user-user signalling is limited by flow control procedures provided by
the ISDN or the public CS. The exchange of user-to-user information is not a network acknowledged
service. Any acknowledgement procedure shall be controlled at a higher layer between public CSs.
Three PHS-UUS services associated with circuit-switched calls that may be provided by the network
to users are:i) PHS-UUS service 1 – User-user information exchanged during the setup and clearing
phases of a call, by transporting User-user information element within B-IF2.02 [1] call
control messages;ii) PHS-UUS service 2 – User-user information exchanged from the sender’s point of view
during call establishment, between the ALERTING and CONNECT messages, within
USER INFORMATION messages; andiii) PHS-UUS service 3 – User-user information exchanged while a call is in the Active
state, within USER INFORMATION messages.
All three services may be used separately or in any combination in association with a single call. As
an option, at call set-up, users may be able to specify that the requested PHS user-to-user signalling
service(s) is (are) required for the call, i.e. the call should not be completed if user-to-user
information cannot be passed.
1.2.2 Specific terminology
The public CS is the protocol entity at the public CS side of the public CS-ISDN interface.
The ISDN is the protocol entity at the ISDN side of the public CS-ISDN interface.
The called public CS is the public CS who is offered an incoming call at the terminating interface.
The calling public CS is the public CS who initiates an outgoing call at the originating interface.
The served user is the user requesting the PHS User to-User (PHS-UUS) supplementary service.

B-IF2.51-02-TS

1

The invoke component is defined in PHS MoU specification B-IF2.02 [1].
1.2.3 Qualifications on the applicability to telecommunications services
See PHS MoU specification B-SV2.70.
1.2.4 Sate definitions
The states associated with basic call control according to B-IF2.02 [1] are applicable.
1.3 Operational requirements
1.3.1 Provision/withdrawal
PHS-UUS services 1 and 2 must be subscribed to by the calling user. PHS-UUS service 3 must be
subscribed to by the served user. Whether these component services are offered to the user as separate
supplementary or in any particular combination is a service provider option. The remote user can
decide to subscribe the service provision or withdrawal as a service provider option.
1.3.2 Requirements on the originating ISDN side
The basic call control procedures according to 5.1/B-IF2.02 [1] are applicable.
The public CS and ISDN supporting PHS-UUS service 1 is expected to be able to receive and send
the User-user information element (see 4.5.30/B-IF2.02 [1]) as described in 1.5.2.1 below. In the caseof explicit activation, it is also expected to support the codings and procedures in 1.5.2.1.
The public CS and ISDN supporting PHS-UUS service 2 is expected to be able to receive and/or send
USER INFORMATION messages containing the PHS User-user information element (see 4.5.30/BIF2.02 [1]) as described in 1.5.2.2.3 below. It is also expected to support the codings and proceduresin 1.5.2.2.
The public CS and ISDN supporting PHS-UUS service 3 is expected to be able to receive and/or send
USER INFORMATION messages containing the User-user information element (see 4.5.30/B-IF2.02[1]) as described in 1.5.2.3.4 below. It is also expected to support the codings and procedures in
1.5.2.3 below. In the case that congestion control is used, it is also expected to support the
CONGESTION CONTROL message and the Congestion Level Information Element (see 4.5.14/BIF2.02 [1]), and to support with the procedures of 1.5.2.3.5 below.
1.3.3 Requirements in the ISDN
Not applicable to B-IF2.51.
1.3.4 Requirements on the terminating ISDN side
The basic call control procedures according to 5.2/B-IF2.02 [1] are applicable.
The public CS and ISDN supporting PHS-UUS service 1 is expected to be able to receive and send
the User-user information element (see 4.5.30/B-IF2.02 [1]) as described in 1.5.2.1 below. In the caseof explicit activation, it is also expected to support the codings and procedures in 1.5.2.1.
The public CS and ISDN supporting PHS-UUS service 2 is expected to be able to receive and/or send
USER INFORMATION messages containing the PHS User-user information element (see 4.5.30/B-

2

B-IF2.51-02-TS

IF2.02 [1]) as described in 1.5.2.2.3 below. It is also expected to support the codings and proceduresin 1.5.2.2.
The public CS and ISDN supporting PHS-UUS service 3 is expected to be able to receive and/or send
USER INFORMATION messages containing the User-user information element (see 4.5.30/B-IF2.02[1]) as described in 1.5.2.3.4 below. It is also expected to support the codings and procedures in
1.5.2.3 below. In the case that congestion control is used, it is also expected to support the
CONGESTION CONTROL message and the Congestion Level Information Element (see 4.5.14/BIF2.02 [1]), and to support with the procedures of 1.5.2.3.5 below.
1.3.5 Assumptions made about the terminal
See PHS MoU specification B-IF1.51.

B-IF2.51-02-TS

3

1.4

Coding requirements

1.4.1

Messages

The following messages are applicable to service activation for PHS-UUS services 1, 2 and 3:
SETUP, CALL PROCEEDING, PROGRESS, ALERTING, CONNECT, DISCONNECT, RELEASE,RELEASE COMPLETE. The FACILITY message is also applicable to the activation of service 3.
The following messages are applicable to the operation of PHS-UUS service 1: SETUP, ALERTING,
CONNECT, DISCONNECT, RELEASE, RELEASE COMPLETE.
The following message is applicable to the operation of PHS-UUS services 2 and 3: USERINFORMATION. Where the congestion control procedures are used, the following message isapplicable to service 3: CONGESTION CONTROL.
The following are message contents for PHS-UUS services.
Message Type: ALERTING

Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =ALERTING

4.4/ B-IF2.02

Both

M

1

Facility

8.2.3/B-IF2.01

Both

O (Note 1)

19

User-user

4.5.30/ B-IF2.02

Both

O (Note 2)

2-131

NOTES
1 Always included for activation of service 2. Always included in public CS - ISDN direction for
explicit activation of PHS-UUS service 1. Not included otherwise for PHS-UUS service 1.
2 May be included for PHS-UUS service 1 (explicit or implicit activation).
3 Other mandatory and optional information elements per PHS MoU specification B-IF2.02.

4

B-IF2.51-02-TS

Message Type: CALL PROCEEDING
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type = CALLPROCEEDING

4.4/ B-IF2.02

Both

M

1

Facility

8.2.3/ B-IF2.01

Both

O (Note 1)

19

NOTES
1 Included only for rejection of explicit PHS-UUS service 1, 2 or 3 request.
2 Other mandatory and optional information elements per PHS MoU specification B-IF2.02.

Message Type: CONGESTION CONTROL
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

N oC

M

1

Call reference

4.3/ B-IF2.02

N oC

M

2-*

Message type =CONGESTIONCONTROL4.4/ B-IF2.02

N oC

M

1

Congestion level

4.5.14/ B-IF2.02

N oC

M

1

Cause

4.5.12/B-IF2.02

N oC

M

4-32

NOTE - Other optional information elements per PHS MoU specification B-IF2.02.

B-IF2.51-02-TS

5

Message Type: CONNECT
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =CONNECT

4.4/ B-IF2.02

Both

M

1

Facility

8.2.3/ B-IF2.01

Both

O (Note 1)

19

User-user

4.5.30/ B-IF2.02

Both

O (Note 2)

2-131

NOTES
1 Always included for PHS-UUS service 3 activation during call establishment. May also be
included for explicit PHS-UUS service 1 activation, if not present in the ALERTING message. Nototherwise included for PHS-UUS service.
2 May be included for PHS-UUS service 1 (explicit or implicit activation). Not included
otherwise.
3 Other mandatory and optional information elements per PHS MoU specification B-IF2.02.

Message Type: DISCONNECT
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =DISCONNECT

4.4/ B-IF2.02

Both

M

1

Facility

8.2.3/ B-IF2.01

Both

O (Note 2)19

User-user

4.5.30/ B-IF2.02

Both

O (Note 1)

2-131

NOTES
1 May be included for PHS-UUS service 1 where DISCONNECT is the first clearing message.
Not included otherwise.
2 May be included to indicate explicit PHS-UUS service/acceptance or PHS-UUS service 1, 2 or
3 rejection.
3 Other mandatory and optional information elements per PHS MoU specification B-IF2.02.

6

B-IF2.51-02-TS

Message Type: FACILITY
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =FACILITY

8.1/ B-IF2.01

Both

M

1

Facility

8.2.3/B-IF2.01

Both

O(Note1)19

NOTES
1 Included for PHS-UUS service 3 activation or deactivation during a call.
2 Other mandatory and optional information elements per PHS MoU specification B-IF2.01.

Message Type: PROGRESS
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =PROGRESS

4.4/ B-IF2.02

Both

M

1

Facility

8.2.3/ B-IF2.01

N oC

O (Note 1)

19

User-user

4.5.30/ B-IF2.02

N oC

O (Note 2)

2-131

NOTES
1 Included only for rejection of explicit PHS-UUS service 1, 2 or 3 request.
2 Included (e.g. in conjunction with in-band tones or announcements) when the PROGRESS
message is sent by the ISDN to indicate that the call has been cleared before reaching the active
state by the remote user, and a User-user information element was present in the clearing message.
3 Other mandatory and optional information elements per PHS MoU specification B-IF2.02.

B-IF2.51-02-TS

7

Message Type: RELEASE
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =RELEASE

4.4/ B-IF2.02

Both

M

1

User-user

4.5.30/ B-IF2.02

Both

O (Note 1)

2-131

NOTES
1 May be included for PHS-UUS service 1 where RELEASE is the first clearing message. Not
included otherwise.
2 Other mandatory and optional information elements per PHS MoU specification B-IF2.02.

Message Type: RELEASE COMPLETE
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =RELEASECOMPLETE

4.4/ B-IF2.02

Both

M

1

Facility

8.2.3/ B-IF2.01

Both

O (Note 2)19

User-user

4.5.30/ B-IF2.02

C o N

O (Note 1)

2-131

NOTES
1 May be included for PHS-UUS service 1 where a RELEASE COMPLETE message is sent by
thepublic CS to reject an incoming SETUP message. Not included otherwise.
2 May be included to indicate explicit PHS-UUS service/acceptance or PHS-UUS service 1,2 or 3
rejection.
3 Other mandatory and optional information elements per PHS MoU specification B-IF2.02.

8

B-IF2.51-02-TS

Message Type: SETUP
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =SETUP

4.4/ B-IF2.02

Both

M

1

Facility

8.2.3/ B-IF2.01

Both

O (Note 1)

19

User-user

4.5.30/ B-IF2.02

Both

O (Note 2)

2-131

NOTES
1 Always included for explicit PHS-UUS service 1 , 2 and 3 activation during call establishment.
2 Always included for implicit service 1 activation; the length must be at least three octets. May
also be included for PHS-UUS service 1 when explicit activation is used. Not included otherwise.
3 Other mandatory and optional information elements per PHS MoU specification B-IF2.02.
Message Type: USER INFORMATION
Information element

Reference

Direction

Type

LengthProtocol discriminator4.2/ B-IF2.02

Both

M

1

Call reference

4.3/ B-IF2.02

Both

M

2-*

Message type =USER
INFORMATION

4.4/ B-IF2.02

Both

M

1

More data

4.5.20/ B-IF2.02

Both

O

1

Facility

8.2.3/B-IF2.01

Both

O (Note 1)

14

User-user

4.5.30/ B-IF2.02

Both

M

2-131

NOTES
1 Included in conjunction with interaction with the ISDN Conference Call Add-on supplementary
service if USER INFORMATION messages are sent/received to/from a specific conferee.
2 Other mandatory and optional information elements per PHS MoU specificationB-IF2.02.

1.4.2

Codesets

All information elements are in codeset 0.
1.4.3

Information elements

The Facility information element is applicable to functional service activation for PHS-UUS services
1, 2 and 3.
The User-user information element is applicable to the operation of PHS-UUS service 1, 2 and 3.
The More data information element is applicable to the operation of PHS-UUS services 2 and 3.

B-IF2.51-02-TS

9

The Congestion level information element is applicable to the operation of PHS-UUS service 3.
1.4.4

Codepoints

1.4.4.1 Syntax for service activation using the Facility information element
Table 1-1 shows the definition of the operation required for the PHS-UUS supplementary service
using ASN.1 as specified in Recommendation X.680 [4] and using the remote operations information
objects as defined in Annex A/X.880 [5].
The coding of the operation specific fields of the invoke component is shown in Figure 1-1 and Table
1-1.
TABLE 1-1/IF2.51
Definition of operations and errors
PHS-User-User-Signalling-Operations{itu-t(0) administration(2) japan(440) isdn(102) phs(4) module(0) phs-user-to-user-signalling-operations(3)version1(1)}DEFINITIONS
::=
BEGIN
IMPORTSOPERATION,ERRORFROM Remote-Operations-Information-Objects{ joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) }rejectedByNetwork, rejectedByUser
FROM General-Error-List{ ccitt recommendation q 950 general-error-list (1) };pHSUserUserService OPERATION::={
ARGUMENT SEQUENCE { [1] IMPLICIT Service,[2] IMPLICIT Preferred }RETURN RESULT TRUEERRORS { rejectedByNetwork | rejectedByUser }CODE opcode-phsUserUserService}
Service::= INTEGER { service1(1), service2(2), service3(3) } (1...3)
Preferred::= BOOLEAN {preferred (TRUE),
required (FALSE) }opcode-phsUserUserService Code ::= global :{itu-t(0) administration(2) japan(440) isdn(102) phs(4)operation(1) phs-user-user-service(4)}END

10 B-IF2.51-02-TS

1.4.4.2 Coding of the PHS-UUS service operation component
See Figure 1-1.
Octet

8

15.1

5

0

Form
1

1

LengthFormat015.3.1

0

Form
0

0

LengthFormat
0

3

2

1

0

Sequence tag
0

0

0

0

1

1

0

0

1

0

Service tag
0Length of service

15.3.3Service15.3.4Class
1

15.3.5

4

Length of sequence tag

Class
1

15.3.2

6

Class
0

15.2

7

LengthFormat
0

0

0

Form
0

0

15.3.6Preferred tag
0

0

0

0

Length preferred00PreferredFigure 1-1/B-B-IF2.51
Facility information element - Invoke component - Operation-specificfields for PHS-UUS supplementary service
Class (octets 15.1, 15.3.1 and 15.3.4)
bits
87
00
Universal
10
Context Specific
All other values reserved.
Form (octets 15.1, 15.3.1 and 15.3.4)
bit
60
Primitive
1
Constructor

B-IF2.51-02-TS

11

Length format (octets 15.2, 15.3.2 and 15.3.5)
bit
80
Length is one octet
Length of sequence (octet 15.2)
This field indicates the total length of the following sequence of fields (i.e. octet 15.3.1 and its
subparts). It is the binary coding of the number of octets of the service, with bit 1 as the leastsignificant bit.
Length of service (octet 15.3.2)
This field indicates the total length of the contents of the service field (i.e. octet 15.3.3). It is thebinary coding of the number of octets of the service, with bit 1 as the least significant bit.
Service (octet 15.3.3)
bits87654321
00000001
PHS-UUS service 100000010
PHS-UUS service 200000011
PHS-UUS service 3
All other values reserved.
Length of preferred (octet 15.3.5)
This field indicates the total length of the preferred field (i.e. octet 15.3.6). It is the binary coding ofoctets of the preferred field with bit 1 as the least significant bit.
Preferred (octet 15.3.6)
bits87654321
00000000
False (service is required)
00000001
True (service is preferred) (see Note)
NOTE - Any value other than “0000 0000” represents the value True.
1.5

Signalling requirements

1.5.1

Activation/deactivation/registration

PHS-UUS services 1, 2 and 3 may be provided on a per call basis following an explicit request from apublic CS. The standard explicit activation procedure makes use of the Facility information element
defined in PHS MoU specification B-IF2.01[2].
PHS-UUS service 1 may also be activated implicitly as described in 1.5.2.1.1.1 below. In this case,activation and operation of the service are indistinguishable.
Procedures for call establishment are described in PHS MoU specification B-IF2.02 [1] with thefollowing modifications. On call request, the SETUP message sent by the calling public CS shallcontain independent PHS-UUS service 1, 2 and 3 requests.
The SETUP message sent by the ISDN towards the called public CS shall also contain the same
independent service requests. If the called public CS can support the indicated services requested by

12 B-IF2.51-02-TS

the explicit mechanism, then specific service acceptances shall be indicated in the appropriate
message(s) as defined in 1.5.2.1, 1.5.2.2 and 1.5.2.3 below.
Deactivation procedures are not required to support these services.
1.5.2

Invocation and operation

1.5.2.1 PHS-UUS service 1
1.5.2.1.1 Call establishment phase
1.5.2.1.1.1

Implicit operation

PHS-UUS service 1 may be implicitly requested by including a User-user information element ofvariable length as specified in 4.5/B-IF2.02 [1] in the SETUP message, transferred across the public
CS-ISDN interface at the calling side as described in 5.1.1/B-IF2.02 [1]. This information element istransported by the ISDN and delivered unchanged in the User-user information element included in
the SETUP message transferred across the public CS-ISDN interface at the called side as described in
5.2.1/B-IF2.02 [1]. For activation purposes, this information element must be at least three octets
long, as defined in 4.5/B-IF2.02 [1].
A User-user information element may be included in the ALERTING and/or CONNECT messages
transferred across the public CS-ISDN in the interface at the called side as described in 5.2.5/BIF2.02 [1]. It may also be included in the DISCONNECT or RELEASE COMPLETE message (see1.5.2.1.2). The content of this information element is transported by the ISDN and delivered in theUser-user information element included in the corresponding message(s) transferred across the usernetwork interface at the calling side as described in 5.1.7/B-IF2.02 and 5.1.8/B-IF2.02 [1].
1.5.2.1.1.2

Explicit operation (preferred or required)Procedures for call establishment are as described in 5.1/B-IF2.02 and 5.2/B-IF2.02 [1] and1.5.2.1.1.1 above, with the following modifications.
On call request, the SETUP message sent by the calling public CS shall contain an explicit PHS-UUS
service 1 request. The SETUP message sent by the ISDN at the called side shall also contain an
explicit service 1 request. The SETUP message sent by the calling public CS may contain a User-user
information element. The SETUP message sent by the ISDN at the called side shall also contain aUser-user information element if present in the SETUP message sent by the calling user.
If the called public CS can support the transfer of User-user information elements in callestablishment and clearing messages, a service 1 acceptance shall be included ina) the ALERTING or CONNECT or first clearing messages prior to the Active state;This explicit PHS-UUS service 1 acceptance shall be forwarded by the ISDN to the calling public CS
in the ALERTING, CONNECT or DISCONNECT message.

B-IF2.51-02-TS

13

A User-user information element may be included in the ALERTING message and/or CONNECT
message transferred across the public CS-ISDN interface at the called side as described in 5.2.5/ BIF2.02 [1].
1.5.2.1.2 Call clearing phase
A User-user information element may be included in the first message used to initiate the normal call
clearing phase (see5.3.3/ B-IF2.02 and 5.3.4/ B-IF2.02 [1]).
The information contained in such an information element is transferred to the remote public CS in
the first clearing message (see 5.3.3/B-IF2.02 and 5.3.4/B-IF2.02[1]). Such a transfer is only
performed if the information is received at the local exchange of the remote public CS before sending
a clearing message to that public CS; otherwise, the information is discarded without sending any
notification.
A User-user information element may be included in the first normal clearing message sent by thecalled public CS during call establishment at the destination interface.
If the called public CS rejects the call with a clearing message containing a User-user information
element, the ISDN shall deliver the User-user information element in the DISCONNECT message
sent to the calling public CS. However, if the ISDN is providing in-band information to the calling
public CS, and chooses not to initiate clearing procedures at that time, the ISDN may deliver theUser-user information element in a PROGRESS message sent to the calling public CS.
NOTE - It is intended that this capability may be used to provide the clearing data transfer(i.e. conveyance of the NS-User-Data parameter to the N-Disconnect primitives) describedin CCITT Rec. X.213 [6] | ISO 8348.
1.5.2.1.3 Actions at the transit exchange
Not applicable to PHS MoU specification B-IF2.51.
1.5.2.1.4 Exceptional procedures
1.5.2.1.4.1 Rejection of implicit service requests. The ISDN shall discard the User-user information
element if it is received from the calling public CS in a SETUP message, but the calling user has not
subscribed to PHS-UUS service 1. If the discard occurs, the ISDN shall continue to process the callrequest. The ISDN may also inform the calling public CS that the PHS-UUS request is not acceptedby sending a STATUS message containing cause #50, “requested facility non-subscribed”, or cause#43, “access information discarded”.

14 B-IF2.51-02-TS

The called user may not be able to interpret incoming User-user information elements. In suchsituations, the user should discard this information without disrupting normal call handling. No
specific signalling is provided by the ISDN to accommodate this situation.
1.5.2.1.4.2

Rejection of explicit service requests

General exceptional procedures are described in 6.3.6/B-IF2.01 [2] and specific exceptional
procedures are described below.
If the ISDN cannot support PHS-UUS service 1, or the calling user has not subscribed to the service,
and it was requested as preferred, a PHS-UUS service 1 rejection indicating “rejected by network” isincluded in the CALL PROCEEDING, PROGRESS, ALERTING or CONNECT message, dependingon the state of the call at the time that the ISDN determines that it cannot support the service.
If the PHS-UUS service 1 request indicated required and the ISDN cannot support it (e.g. because it is
not implemented or because of temporary inability to provide the service), a DISCONNECT or
RELEASE COMPLETE message (depending on the state of the call) is sent with cause #47 “resource
unavailable, unspecified” or cause #69 “requested facility not implemented” and a PHS-UUS service
1 rejection indicating “rejected by network”.
If the PHS-UUS service 1 request indicated required and the calling user has not subscribed to theservice, a DISCONNECT or RELEASE COMPLETE message is sent with cause #50 “requested
facility not subscribed” and a PHS-UUS service 1 rejection indicating “rejected by network”.
If the called public CS receives a service 1 rejection,, and the service 1 was requested as preferred, therejection indicating “rejected by user” is included ina)the ALERTING or CONNECT message;b)

the first clearing messages prior to the Active state.

This explicit PHS-UUS service 1 rejection shall be forwarded by the ISDN to the calling public CS in
the ALERTING or CONNECT message and may be forwarded in the DISCONNECT message.
If the called public CS receives a PHS-UUS service 1 rejection,, and the PHS-UUS service 1 wasrequested as required, the srejection indicating “rejected by user” is included in a DISCONNECT or
RELEASE COMPLETE message with cause #69 “requested facility not implemented”. This explicit
PHS-UUS service 1 rejection may be forwarded by the ISDN to the calling public CS in the
DISCONNECT message.
If the called public CS(s) does(do) not include a PHS-UUS service 1 acceptance or rejection in the
ALERTING, CONNECT, DISCONNECT or RELEASE COMPLETE message, and the PHS-UUS
service 1 request indicated preferred, the ISDN shall return an explicit rejection indicating “rejectedby user” in the CONNECT or DISCONNECT message sent to the calling public CS.
If the called public CS(s) does(do) not include a PHS-UUS service 1 acceptance or rejection in the
ALERTING or CONNECT message, and the PHS-UUS service 1 request indicated required, the
ISDN shall clear the call by sending a DISCONNECT message to the calling public CS with cause

B-IF2.51-02-TS

15

#69 “requested facility not implemented” and a PHS-UUS service 1 rejection indicating “rejected byuser”. Furthermore, a DISCONNECT message with cause #31 “normal, unspecified” shall be sent tothe called public CS.
If the called public CS(s) does(do) not include a PHS-UUS service 1 acceptance or rejection in the
DISCONNECT or RELEASE COMPLETE message, and the PHS-UUS service 1 request indicatedrequired, the ISDN shall include a service 1 rejection indicating “rejected by user” in the
DISCONNECT message sent to the calling public CS.
1.5.2.1.4.3

Unexpected User-user information element in call control messages

The ISDN shall discard the User-user information element if it is received from the called public CS
in the ALERTING or CONNECT message, but a request for PHS-UUS was not indicated (either
explicitly or implicitly) in the SETUP message delivered to the called public CS. If discard occurs,
the ISDN shall take action on the remaining contents of the message received from the calling public
CS and shall send a STATUS message to the called public CS containing cause #43, “accessinformation discarded”.
The ISDN shall discard the User-user information element if it is received from either public CS in a
DISCONNECT, RELEASE or RELEASE COMPLETE message, but a request for PHS-UUS was notindicated in the SETUP message delivered to the called public CS. If discard occurs, the ISDN shalltake action on the remaining contents of the message received from the public CS. If the clearing
party has sent a DISCONNECT (or RELEASE) message, the ISDN shall send to the clearing party a
RELEASE (or RELEASE COMPLETE) message containing cause #43, “access information
discarded”. If the clearing party had sent a RELEASE COMPLETE message, the ISDN shall consider
the call as cleared to that party; no additional action shall be taken.
The ISDN shall discard the User-user information element in the following cases not explicitly
discussed elsewhere in 1.5:-

the overall length of the User-user information element is greater than 131 octets and
PHS-UUS service 1 was activated either explicitly or implicitly;-

the ISDN receives a message containing the User-user information element, but thatmessage is not allowed to contain PHS-UUS as defined by this document.

If discard occurs, the ISDN shall take action on the remaining contents of the message received fromthe sending public CS and shall send a STATUS message to that public CS containing cause #43,
“access information discarded”. However, if the ISDN discards a User-user information element froma received clearing message, the ISDN shall include cause #43, “access information discarded”, in thenext sequential clearing message sent to the public CS as specified in 5.3/B-IF2.02 [1]. If the ISDN
discards a User-user information element from a RELEASE COMPLETE message, the ISDN shallconsider the call as cleared to that party; no additional action shall be taken.

16 B-IF2.51-02-TS

1.5.2.2 PHS-UUS service 2
1.5.2.2.1 Call establishment phaseOn call request, the SETUP message sent by the calling public CS shall contain an explicit PHS-UUS
service 2 request. The SETUP message sent by the ISDN at the called side, shall also contain an
explicit PHS-UUS service 2 request.
If the called public CS can support USER INFORMATION messages during call establishment, a
PHS-UUS service 2 acceptance shall be included in the ALERTING message sent to the ISDN. Thisexplicit acceptance indication shall be forwarded in the ALERTING message sent by the ISDN to thecalling public CS .
1.5.2.2.2 Actions at the transit exchange
Not applicable to B-IF2.51.
1.5.2.2.3 Transfer of USER INFORMATION messages
Once an ALERTING message has been received, both the involved public CS can transfer
information between themselves by transferring USER INFORMATION messages across the public
CS-ISDN interface. The ISDN provides for the transfer of such messages from the calling to thecalled side and vice versa. The USER INFORMATION message included the call reference, theprotocol discriminator, and the User-user information element as defined in 1.4.1 in this B-IF2.51.
The More data information element may also be included by the source user to indicate to the remoteuser that another USER INFORMATION message shall follow, containing information elements
belonging to the same block. The use of a More data information element is not supervised by the
ISDN.
When PHS-UUS service 2 is provided, no more than two USER INFORMATION messages may betransferred in each direction after the ALERTING message and before the CONNECT message.
As a network option, USER INFORMATION messages may be transferred to the called public CS in
the Active state.
Sending or receiving of USER INFORMATION messages does not change the state of the call.
1.5.2.2.4 Exceptional procedures
1.5.2.2.4.1

Service rejection/non-acceptance

General exceptional procedures are described in 6.3.6/B-IF2.01 [2] and specific exceptional
procedures are described below.
If the ISDN cannot support PHS-UUS service 2, or the calling user has not subscribed to the service,
and it was requested as preferred, a PHS-UUS service 2 rejection indicating “rejected by network” isincluded in a CALL PROCEEDING, PROGRESS or ALERTING message, depending on the state of
the call at the time that ISDN determines that it cannot support the service.

B-IF2.51-02-TS

17

If the PHS-UUS service 2 request indicated required and the ISDN cannot support it (e.g. because it is
not implemented or because of temporary inability to provide the service), a DISCONNECT or
RELEASE COMPLETE message (depending on the state of the call) is sent with cause #47,
“resource unavailable, unspecified”, or cause #69, “requested facility not implemented”, and a PHSUUS service 2 rejection indicating “rejected by network”.
If the PHS-UUS service 2 request indicated required and the calling user has not subscribed to theservice, a DISCONNECT or RELEASE COMPLETE message is sent with cause #50, “requested
facility not subscribed”, and a PHS-UUS service 2 rejection indicating “rejected by network”.
If the called public CS receives a PHS-UUS service 2 rejection , and it was requested as preferred, a
PHS-UUS service 2 rejection indicating “rejected by user” is included in the ALERTING message.
This explicit PHS-UUS service 2 rejection shall be forwarded by the ISDN to the calling public CS in
the ALERTING message.
If the called public CS receives a PHS-UUS service 2 rejection , and it was requested as required, a
PHS-UUS service 2 rejection indicating “rejected by user” is included in a DISCONNECT or
RELEASE COMPLETE message with cause #69, “requested facility not implemented”. This explicit
PHS-UUS service 2 rejection may be forwarded by the ISDN to the calling public CS user in the
DISCONNECT message.
If the called public CS(s) does(do) not include a PHS-UUS service 2 acceptance or rejection in the
ALERTING message or a rejection in the DISCONNECT or RELEASE COMPLETE message andthe request indicated preferred, the ISDN shall return an explicit rejection indicating “rejected byuser” in the ALERTING or DISCONNECT message sent to the calling public CS.
If the called public CS(s) does(do) not include a PHS-UUS service 2 acceptance or rejection in the
ALERTING message and the request indicated required, the ISDN shall clear the call by sending a
DISCONNECT message to the calling public CS with cause #69, “requested facility not
implemented”, and a PHS-UUS service 2 rejection indicating “rejected by user”. Furthermore, a
DISCONNECT message with cause #31, “normal, unspecified”, shall be sent to the called public CS.
If the called public CS(s) does(do) not include a PHS-UUS service 2 rejection in the DISCONNECT
or RELEASE COMPLETE message and the request indicated required, the ISDN shall include a
PHS-UUS service 2 rejection indicating “rejected by user” in the DISCONNECT message with cause#31, “normal, unspecified”, shall be sent to the calling public CS.
1.5.2.2.4.2

Excess USER INFORMATION messages

In the following cases, the ISDN shall discard the USER INFORMATION message and send a
STATUS message with cause #43, “access information discarded”, to the sending public CS :– if the ISDN receives a USER INFORMATION message in the alerting phase, but PHS-UUS
service 2 is not activated;– if the ISDN receives more than two USER INFORMATION messages from a public CS;

18 B-IF2.51-02-TS

– if the ISDN receives a USER INFORMATION message in any other call phase than thealerting phase.
1.5.2.3 PHS-UUS service 3This service may be requested during call establishment or during the Active state of the call.
1.5.2.3.1 Call establishment phaseOn call request, the SETUP message sent by the calling public CS shall contain an explicit PHS-UUS
service 3 request. The SETUP message sent by the ISDN at the called side shall also contain an
explicit PHS-UUS service 3 request.
If the called public CS can support USER INFORMATION message transfer during the Active state,a PHS-UUS service 3 acceptance shall be included in the CONNECT message.
1.5.2.3.2 Call active phase
During the Active state of a call, a public CS may request PHS-UUS service 3 preferred only. A
FACILITY message indicating a PHS-UUS service 3 request is sent from the requesting public CS to
the ISDN. The ISDN shall indicate the PHS-UUS service 3 request to the public CS that did not
request PHS-UUS service 3 in the FACILITY message and start timer T1 at the ISDN interface of therequesting public CS.
If the public CS that did not request PHS-UUS service 3 can support the transfer of USERINFORMATION messages during the Active state, a PHS-UUS service 3 acceptance is returned in
the FACILITY message. This explicit acceptance is conveyed back to the requesting public CS in a
FACILITY message and the ISDN shall stop timer T1.
1.5.2.3.3 Actions at the transit exchange
Not applicable to B-IF2.51.
1.5.2.3.4 Transfer of USER INFORMATION messages
When a call is in the Active state, with PHS-UUS service 3 activated, one public CS may transfer
information to the other by conveying USER INFORMATION messages across the public CS - ISDN
interface. The ISDN provides for the transport of such messages. The USER INFORMATION
message includes the call reference, protocol discriminator, and the User-user information element.
The More data information element may also be included by the source public CS to indicate to theremote public CS that another USER INFORMATION message shall follow, containing information
belonging to the same block. The use of the More data information element is not supervised by the
ISDN; in particular, integrity of blocks fragmented using this procedure is not guaranteed.
1.5.2.3.5 Congestion control of USER INFORMATION messages
Network flow control mechanisms shall exist after the call has entered the Active call state to restrict
USER INFORMATION message flow in each direction.

B-IF2.51-02-TS

19

In each direction a burst capability of sending N USER INFORMATION messages shall immediately
be available to each public CS , where N initially equals the value of the burst parameter X. The valueof N shall be decremented by one for every USER INFORMATION message sent by the public CS
and incremented by Y at regular intervals of T subject to the limitation that N shall not exceed X.
The burst parameter X shall be set to a value of X = 16 and the replenishment parameter Y shall be
set to Y = 8.
NOTE – While some ISDNs may support higher values of X and Y, the value of X and Y
for international calls shall be set as above. It is up to the ISDN using higher values to takethe appropriate actions, unless bilateral agreements exist.
If the ISDN within the period T receives more than N USER INFORMATION messages, the excess
message(s) shall be discarded. The ISDN shall respond to the first discarded messages with a
CONGESTION CONTROL message including a Congestion level information element indicating“receive not ready”. The CONGESTION CONTROL message shall also include a cause #43, “accessinformation discarded”. Subsequent received USER INFORMATION messages shall be discarded by
the ISDN without any indication to the public CS.
When the flow control restrictions are removed (i.e. timer T expires) then, if a USERINFORMATION message has been discarded due to that restriction, a CONGESTION CONTROL
message indicating “receive ready” shall be sent to the public CS. If no USER INFORMATION has
been discarded, no indication shall be sent. The public CS cannot flow control USERINFORMATION messages received from the ISDN .
If the ISDN receives a CONGESTION CONTROL message from the public CS, a STATUS message
with causes #111 “protocol error, unspecified” shall be sent to the public CS and no further action
shall be taken.
1.5.2.3.6

Exceptional procedures

1.5.2.3.6.1

Rejection of service requested during call establishment

General exceptional procedures are described in 6.3.6/B-IF2.01 [2] and specific exceptional
procedures are described below.
If the ISDN cannot support PHS-UUS service 3, or the calling user has not subscribed to the service,
and it was requested as preferred, a PHS-UUS service 3 rejection indicating “rejected by network” isincluded in a CALL PROCEEDING, PROGRESS, ALERTING or CONNECT message, dependingon the state of the call at the time that the ISDN determines that it cannot support the service.
If the PHS-UUS service 3 request indicated required and the ISDN cannot support it (e.g. because it is
not implemented or because of temporary inability to provide the service), a DISCONNECT or
RELEASE COMPLETE message (depending on the state of the call) is sent with cause #47 “resource
unavailable, unspecified” or cause #69 “requested facility not implemented”, and a PHS-UUS service
3 rejection indicating “rejected by network”.

20 B-IF2.51-02-TS

If the PHS-UUS service 3 request indicated required and the calling user has not subscribed to theservice, a DISCONNECT or RELEASE COMPLETE message is sent with cause #50 “requested
facility not subscribed”, and a PHS-UUS service 3 rejection indicating “rejected by network”.
If the called public CS receives a PHS-UUS service 3 rejection, and it was requested as preferred, the
PHS-UUS service 3 rejection indicating “rejected by user” is included in the CONNECT message.
This explicit PHS-UUS service 3 rejection shall be forwarded by the ISDN to the calling public CS in
the CONNECT message.
If the called public CS receives a PHS-UUS service 3 rejection, and it was requested as required, the
PHS-UUS service 3 rejection indicating “rejected by user” is included in a DISCONNECT or
RELEASE COMPLETE message with cause #69 “requested facility not implemented”. This explicit
PHS-UUS service 3 rejection may be forwarded by the ISDN to the calling public CS in the
DISCONNECT message.
If the called public CS(s) does(do) not include a PHS-UUS service 3 acceptance or rejection in the
CONNECT message or a rejection in the DISCONNECT or RELEASE COMPLETE message and therequest indicated preferred, the ISDN shall return an explicit rejection indicating “rejected by user” in
the CONNECT or DISCONNECT message sent to the calling public CS.
If the called public CS(s) does(do) not include a PHS-UUS service 3 acceptance or rejection in the
CONNECT message and request indicated required, the ISDN shall clear the call by sending a
DISCONNECT message to the calling public CS with cause #69 “requested facility not
implemented”, and PHS-UUS service 3 rejection indicating “rejected by user”. Furthermore, a
DISCONNECT message with cause #31, “normal, unspecified”, shall be sent to the called public CS.
If the called public CS(s) does(do) not include a PHS-UUS service 3 rejection indicating “rejected byuser” in the DISCONNECT or RELEASE COMPLETE message and the request indicated required,the ISDN shall include a PHS-UUS service 3 rejection in the DISCONNECT message sent to thecalling public CS.
1.5.2.3.6.2

Rejection of service requested after call establishment

General exceptional procedures are described in 6.3.6/B-IF2.01 [2] and specific exceptional
procedures are described below.
If the ISDN cannot support PHS-UUS service 3, or the requesting user has not subscribed to theservice, a PHS-UUS service 3 rejection indicating “rejected by network” is included in a FACILITY
message.
If the public CS that did not request PHS-UUS service 3 receives a PHS-UUS service 3 rejection, a
PHS-UUS service 3 rejection indicating “rejected by user” shall be returned in the FACILITY
message and stop timer T1.
If the requested public CS does not respond to the PHS-UUS service 3 request before timer T1
expires, the ISDN shall return a PHS-UUS service 3 rejection indicating “rejected by user” to therequesting public CS.

B-IF2.51-02-TS

21

Collision of requests for PHS-UUS service 3 occurs when there is an outstanding request for PHSUUS service 3 and a subsequent request is received from the called public CS. In this situation, theentities (user or network) observing the collision shall reject the second request with a FACILITY
message including a PHS-UUS service 3 rejection indicating “rejected by user” or “rejected by
network”. Consequently, both requests will be rejected.
1.5.2.3.6.3

Receipt of unexpected USER INFORMATION messages

Whenever a USER INFORMATION message is received from the public CS anda) it is not allowed in the current call state (e.g. in any other state than Active where only PHSUUS service 3 is activated); and/orb) the appropriate PHS-UUS service has not been activated,the message shall be discarded by the ISDN. The ISDN shall also send a STATUS message
with a cause #43 “access information discarded”.
1.6 Interaction with other supplementary services
1.6.1 DTMF Transmission
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
1.6.2 Handover
PHS-UUS service is not activated by handover activation.
UUI and /or explicit request included in the SETUP message for Handover activation will be
neglected.
PHS-UUS Service 1:
No impact, i.e. handover service does not affect the operation of PHS-UUS service 1, except forfollowing case.
UUI incoming to PHS user with handover activated:
If UUI transmission from PHS-NW to a PHS user is not completed, PHS user may not receive UUI.
PHS-UUS Service 2:
No impact, i.e. handover service does not affect the operation of PHS-UUS service 2.
PHS-UUS Service 3:
No impact, i.e. handover service does not affect the operation of PHS-UUS service 3, except forfollowing cases.

22 B-IF2.51-02-TS

Handover Activated by PHS user during UUI transmission:
PHS user may not receive UUI.
Note - In this case, acknowledgment of UUI receipt may be done and UUI may be re-transmitted
between end-to-end on high layer after the handover operation.
UUI incoming to a PHS user with handover activated:
If UUI transmission from PHS-NW to a PHS user is not completed, the PHS user may not receive
UUI.
1.6.3 User scrambling
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
1.6.4 Subaddress
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
1.6.5 Calling User Identification Presentation
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
1.6.6 Calling User Identification Restriction
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
1.6.7 Call Forwarding
1.6.7.1 Call Forwarding Unconditional (CFU)
Calls originated by a PHS user with call forwarding unconditional activated;
Since call forwarding unconditional does not affect the forwarding user's ability to make outgoingcalls, a PHS user with call forwarding unconditional activated can send and receive UUI in
association with ongoing call or at the set-up of a new call.
Calls incoming to a PHS user with call forwarding unconditional activated;
Any UUI or request for PHS-UUS that accompanies the set-up request shall be forwarded with thecall.
Note - As a network provider option, the forwarding of UUI and/or PHS-UUS requests can be
restricted to forwarding users who subscribe to the relevant PHS-UUS supplementary service.
After forwarding;

B-IF2.51-02-TS

23

PHS-UUS service 3 may be requested during the active phase of the call.
1.6.7.2 Call Forwarding on PS Busy (CFB)
See interaction with call forwarding unconditional. However, if a PHS user determined user busy
condition exists, any UUI and/or request for PHS-UUS shall also be delivered to the forwarding userwhen the call is offered.
1.6.7.3 Call Forwarding on No Reply (CFNRy)
Calls originated by a PHS user with call forwarding no reply activated:;
Since call forwarding no reply does not affect the forwarding user's ability to make outgoing calls, a
PHS user with call forwarding no reply activated can send UUI in association with an ongoing call orat the set-up of a new call.
Calls incoming to a PHS user with call forwarding no reply activated;
PHS-UUS service 1;
If the PHS-UUS service is explicitly requested and the forwarding user explicitly rejects the request,
the PHS-UUS request and the UUI (if any) shall not be forwarded with the call. However, if therequest was indicated as "UUI required" and either the forwarding or forwarded-to-user explicitly
rejects the request, the call shall be rejected. In all other cases the PHS-UUS request and/or UUI shallbe forwarded or delivered with the call.
PHS-UUS service 2;
If the PHS-UUS service is requested as "UUI not required", the call will be forwarded without the
PHS-UUS request. If the PHS-UUS service is requested as "UUI required", call forwarding no reply
shall be overridden (i.e. the call is treated as if call forwarding no reply was not activated).
PHS-UUS service 3;
Any request for PHS-UUS service 3 that accompanies the set-up request shall be forwarded with thecall.
Note - As a network provider option, the forwarding of UUI and/or PHS-UUS requests can be
restricted to forwarding users who subscribe to the relevant PHS-UUS supplementary service.
After forwarding;
PHS-UUS Service 3 may be requested during the active phase of the call.
1.6.7.4 Call Forwarding on PS Not Reachable (CFNRc)
See interaction with call forwarding unconditional.

24 B-IF2.51-02-TS

1.6.8 Call Barring
1.6.8.1 Barring of All Outgoing Calls (BAOC)
No impact, i.e. neither supplementary service affects the operation of the other supplementary
service. (When outgoing call is possible only under the conditions of BAOC, UUI and/or request of
PHS-UUS may be sent or received.)
1.6.8.2 Barring of Outgoing International Calls (BOIC)
No impact, i.e. neither supplementary service affects the operation of the other supplementary
service. (UUI and/or request of PHS-UUS may be sent to or received from the party to which
outgoing call is possible only under the conditions of BOIC.)
1.6.8.3 Barring of Outgoing International Calls Except Call to Home Country (BOIC-exHC)
No impact, i.e. neither supplementary service affects the operation of the other supplementary
service. (UUI and/or request of PHS-UUS may be sent to or received from the party to which
outgoing call is possible only under the conditions of BOIC-exHC.)
1.6.8.4 Barring of All Incoming Calls (BAIC)No impact, i.e. neither supplementary service affects the operation of the other supplementary
service.
(UUI and/or request of PHS-UUS may be sent to or received from the party to which incoming call ispossible only under the conditions of BAIC.)
1.6.8.5 Barring of Incoming Calls on Roaming outside Home Country (BIC-roam)
No impact, i.e. neither supplementary service affects the operation of the other supplementary
service.
(UUI and/or request of PHS-UUS may be sent to or received from the party to which incoming call ispossible only under the conditions of BIC-roam.)
1.6.9 Roaming
Further Study.
1.7 Interaction with other networks
1.7.1 Interaction with other PHS network
UUI can be delivered when the other PHS network have the function of PHS-UUS supplementary
service.

B-IF2.51-02-TS25

1.7.1.1 PHS-UUS Service 1
No impact.
1.7.1.2 PHS-UUS Service 2
No impact.
1.7.1.3 PHS-UUS Service 3
No impact.
1.7.2 Interaction with ISDN network
The UUI will be transmitted to and /or from the ISDN network that provides the UUS supplementary
service.
1.7.2.1 Originating call from ISDN network
1.7.2.1.1 PHS-UUS Service 1
No impact.
1.7.2.1.2 PHS-UUS Service 2
No impact.
1.7.2.1.3 PHS-UUS Service 3
No impact.
1.7.2.2 Originating call from PHS network
1.7.2.2.1 PHS-UUS Service 1
No impact.
1.7.2.2.2 PHS-UUS Service 2
No impact.
1.7.2.2.3 PHS-UUS Service 3
No impact.
1.8 Signaling flow

26 B-IF2.51-02-TS

In addition to basic call control according to B-IF2.02, the signaling flow described in B-IF0.51 isadded for your reference.
1.9 Parameter values (timers)
The value of network timer T is set to 10 seconds.
The value of network timer T1 is set to 10 seconds.
1.10 Dynamic Description (SDLs)
See Annex A/B-IF-2.02.

B-IF2.51-02-TS

27