PHS MoU Document
B-IF1.51-02-TS
Title: Public Personal Handy-Phone System : Common Air Interface
Specification - PHS User-to-User Signalling Version: 02
Date: July 14, 1999
PHS MoU Classification: Unrestricted
List of contents:<Summary>
1. Relation with international standards
2. References
3. Items for further study
1. PHS User-to-User Signalling (PHS-UUS)
1.1 Definition
1.2 Description
1.3 Operational requirements
1.4 Coding Requirements
1.5 Signalling requirements
Annex A

Number of pages: 29

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-IF1.51-02-TS
VersionHistory of Revised Versions
Date
Outline01

July 31,1998

Established

02

July 14, 1999

Changing the description of “object ID”

B-IF1.51-02-TS

Public Personal Handy-Phone System:
Common Air Interface Specification- PHS User-to-User Signalling -Contents
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

Annex A ......................................................................................................................................24

B-IF1.51-02-TS

L1. PHS User-to-User Signalling (PHS-UUS)
1.1 Definition
The PHS User-to-User Signalling (PHS-UUS) supplementary service allows a public cellstation send/receive the limited amount of the user to user information to/from personal station
via PHS network.
1.2 Description
1.2.1 General description
The PHS-UUS supplementary services provide the communication between two public PS
users by using the air protocol specified in ARIB Standard RCR STD-28[1] for the baseprotocol. 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 signallingis limited by flow control procedures provided by the ISDN or the public CS. The exchange ofuser-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 andclearing phases of a call, by transporting User-user information element within BIF1.01[2] call control messages;ii) PHS-UUS service 2 – User-user information exchanged from the sender’s point ofview 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 theactive 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-touser 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-PS interface.
The PS is the protocol entity at the PS side of the public CS-PS interface.
The called PS is the PS who is offered an incoming call at the terminating interface.
The calling PS is the PS who initiates an outgoing call at the originating interface.

B-IF1.51-02-TS

1

The served user is the user requesting the PHS User-to-User (PHS-UUS) supplementary
service.
The invoke component is defined in PHS MoU specification B-IF1.01[2].
PHS network is defined to include public CS in B-NW0.00[3].
1.2.3 Qualifications on the applicability to telecommunications services
See PHS MoU specification B-SV2.70[4].
1.2.4 State definitions
The states associated with basic call control according to B-IF1.01[2] 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 mustbe 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 CS side
The basic call control procedures according to B-IF1.01[2] are applicable.
The public CS and PS supporting PHS-UUS service 1 is expected to be able to receive and send
the User-user information element (see Annex A/B-IF1.51) as described in 1.5.2.1 below. In
the case of explicit activation, it is also expected to support the codings and procedures in
1.5.2.1.
The public CS and PS 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 (seeAnnex A/B-IF1.51) as described in 1.5.2.2.3 below. It is also expected to support the codings
and procedures in 1.5.2.2.
The public CS and PS supporting PHS-UUS service 3 is expected to be able to receive and/or
send USER INFORMATION messages containing the User-user information element (seeAnnex A/B-IF1.51) 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 expected2

B-IF1.51-02-TS

to support the CONGESTION CONTROL message and the Congestion level information
element (see Annex A/B-IF1.51), and to support with the procedures of 1.5.2.3.5 below.
1.3.3 Requirements in PHS network
Not applicable to B-IF1.51.
1.3.4 Requirements on the terminating CS side
The basic call control procedures according to B-IF1.01[2] are applicable.
The public CS and PS supporting PHS-UUS service 1 is expected to be able to receive and send
the User-user information element (see Annex A/B-IF1.51) as described in 1.5.2.1 below. In
the case of explicit activation, it is also expected to support the codings and procedures in
1.5.2.1.
The public CS and PS 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 (seeAnnex A/B-IF1.51) as described in 1.5.2.2.3 below. It is also expected to support the codings
and procedures in 1.5.2.2.
The public CS and PS supporting PHS-UUS service 3 is expected to be able to receive and/or
send USER INFORMATION messages containing the User-user information element (seeAnnex A/B-IF1.51) 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 Annex A/B-IF1.51), and to support with the procedures of 1.5.2.3.5 below.
1.3.5 Assumptions made about the terminal
Terminal equipment using PHS-UUS service 1 is expected to be able to generate and accept theUser-user information element (see Annex A/B-IF1.51) as described in 1.5.2.1 below. In thecase of explicit activation, it is also expected to support the codings and procedures in 1.5.2.1.
Terminal equipment using PHS-UUS service 2 is expected to be able to generate and/or accept
USER INFORMATION messages containing the PHS User-user information element (seeAnnex A/B-IF1.51)as described in 1.5.2.2.3 below. It is also expected to support the codings
and procedures in 1.5.2.2.
Terminal equipment using PHS-UUS service 3 is expected to be able to generate and/or accept
USER INFORMATION messages containing the PHS User-user information element (seeAnnex A/B-IF1.51)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.

B-IF1.51-02-TS3

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 PHS-UUS
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 PHS-UUS service 3: CONGESTION CONTROL.
The following are message contents for PHS-UUS services.
Message Type: ALERTing

Information element

Reference

Direction

Type

LengthProtocol discriminator

4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.3/RCR
STD-28

Both

M

2-3

Message type=
ALERTing

4.4.3.7.3.4/RCR
STD-28Both

M

1Facility

4.4.3.7.3.5/RCR
STD-28

Both

O*1

19

User-user

Annex A/BIF1.51

Both

O*2

2-131

Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].
*1 Always included for activation of PHS-UUS service 2. Always included in PS - public CS 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).

4

B-IF1.51-02-TS

Message Type: CALL PROCeeding

Information element

Reference

Direction

Type

LengthProtocol discriminator 4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.3/RCR
STD-28

Both

M

2-3

Message type = CALL 4.4.3.7.3.4/RCR
PROCeeding
STD-28Both

M

1Facility

Both

O*1

19

4.4.3.7.3.5/RCR
STD-28Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].

*1 Included only for rejection of explicit PHS-UUS service 1, service 2 or service 3 request.

Message Type: CONGESTION CONTROL

Information element

Reference

Direction

Type

LengthProtocol discriminator 4.4.3.7.3.2/RCR
STD-28downlink

M

1

Call reference

4.4.3.7.3.3/RCR
STD-28downlinkM

2-3

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

downlink

M

1

Congestion level

Annex A/BIF1.51

downlink

M

1

Cause

B-IF1.01[2]downlink

M

4-32

Other optional information elements per PHS MoU specification B-IF2.02[5].

B-IF1.51-02-TS

5

Message Type: CONNect

Information element

Reference

Direction

Type

LengthProtocol discriminator 4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.3/RCR
STD-28

Both

M

2-3

Message type =CONNect

4.4.3.7.3.4/RCR
STD-28Both

M

1Facility

4.4.3.7.3.5/RCR
STD-28

Both

O*1

19

User-user

Annex A/BBoth
O*2
2-131
IF1.51Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].
*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. Not otherwise included for PHS-UUS service.
*2 May be included for PHS-UUS service 1 (explicit or implicit activation). Not included
otherwise.
Message Type: DISConnect

Information element

Reference

Direction

Type

LengthProtocol discriminator 4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.2/RCR
STD-28

Both

M

2-3

Message type =DISConnect

4.4.3.7.3.2/RCR
STD-28Both

M

1Facility

4.4.3.7.3.2/RCR
STD-28

Both

O*1

19

User-user

Annex A/BBoth
O *2
2-131
IF1.51Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].
*1 May be included to indicate explicit service/acceptance or PHS-UUS service 1, 2 or 3
rejection.
*2 May be included for PHS-UUS service 1 where DISConnect is the first clearing message.
Not included otherwise.

6

B-IF1.51-02-TS

Message Type: FACility

Information element

Reference

Direction

Type

LengthProtocol discriminator 4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.3/RCR
STD-28

Both

M

2-3

Message type =FACility

4.4.3.7.3.4/RCR
STD-28Both

M

1Facility

4.4.3.7.3.5/RCR
Both
O*1
19
STD-28Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].
*1 Included for PHS-UUS service 3 activation or deactivation during a call.
Message Type: PROGress

Information element

Reference

Direction

Type

LengthProtocol discriminator

4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.3/RCR
STD-28

Both

M

2-3

Message type =PROGress

4.4.3.7.3.4/RCR
STD-28Both

M

1Facility

4.4.3.7.3.5/RCR
STD-28downlink

O*1

19

User-user

Annex A/Bdownlink
O* 2
2-131
IF1.51Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].
*1 Included only for rejection of explicit PHS-UUS service 1, service 2 or service 3 request.
*2 Included (e.g. in conjunction with in-band tones or announcements) when the PROGressmessage is sent by the public CS 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 theclearing message.

B-IF1.51-02-TS

7

Message Type: RELease

Information element

Reference

Direction

Type

LengthProtocol discriminator 4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.2/RCR
STD-28

Both

M

2-3

Message type =RELease

4.4.3.7.3.2/RCR
STD-28BothM

1User-user

Annex A/BBoth
O*1
2-131
IF1.51Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].
*1 May be included for PHS-UUS service 1 where RELease is the first clearing message. Not
included otherwise.
Message Type: RELease COMPlete

Information element

Reference

Direction

Type

LengthProtocol discriminator

4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.3/RCR
STD-28

Both

M

2-3

Message type=

4.4.3.7.3.4/RCR
STD-28Both

M

1Facility

4.4.3.7.3.5/RCR
STD-28

Both

O*1

19

User-user

Annex A/BIF1.51

uplinkO*2

2-131

RELease COMPlete

Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].
*1 May be included for PHS-UUS service 1 where a RELease COMPlete message is sent by the
PS to reject an incoming SETUP message. Not included otherwise.
*2 May be included to indicate explicit service/acceptance or PHS-UUS service 1,2 or 3
rejection.

8

B-IF1.51-02-TS

Message Type: SETUP
Information element

Reference

Direction

Type

LengthProtocol discriminator

4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.3/RCR
STD-28

Both

M

2-3

Message type=

4.4.3.7.3.4/RCR
STD-28Both

M

1Facility

4.4.3.7.3.5/RCR
STD-28

Both

O*1

19

User-user

Annex A/BIF1.51

Both

O*2

2-131

SETUP

Other mandatory information elements and/or optional information elements also be usedaccording to ARIB Standard RCR STD-28[1].
*1 Always included for explicit PHS-UUS service 1 activation, service 2 activation, andservice 3 activation during call establishment.
*2 Always included for implicit PHS-UUS 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.
Message Type: USER INFORMATION
Information element

Reference

Direction

Type

LengthProtocol discriminator 4.4.3.7.3.2/RCR
STD-28BothM

1Call reference

4.4.3.7.3.2/RCR
STD-28

Both

M

2-3

Message type = USER 4.4/ B-IF2.02[5]INFORMATION

Both

M

1

More data

Annex A/BIF1.51

Both

O

1

Facility

4.4.3.7.3.5/RCR
STD-28

Both

O *1

14

User-user

Annex A/BBoth
M
2-131
IF1.51Other mandatory and optional information elements per PHS MoU specification B-IF2.02[5].
*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.
B-IF1.51-02-TS

9

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.
All information elements are in codeset 0.
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.
The Congestion level information element is applicable to the operation of PHS-UUS service 3.
Above information elements are described in Annex A /B-IF1.51.
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 andTable 1-1.

10

B-IF1.51-02-TS

TABLE 1-1/IF1.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

B-IF1.51-02-TS

11

Octet15.1
15.2
15.3.1
15.3.215.3.315.3.415.3.5

8

7

Class
0
0
LengthFormat0Class
10
LengthFormat
0

6
Form
1

5

3
Sequence tag
1
00
Length of sequence tag

Form
0

0

4

Service tag
00Length of service

2

1

0

0

0

1

1

0

0

1

ServiceClass
1
LengthFormat
0

0

Form
0

0

0

0

0

15.3.6Preferred tag
00Length preferred0Preferred0

Figure 1-1/B-B-IF1.51
Facility information element - Invoke component - Operation-specificfields for PHS-UUS supplementary service

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 requestfrom a PS. The standard explicit activation procedure makes use of the Facility information
element defined in PHS MoU specification B-IF1.01[2].
PHS-UUS service 1 may also be activated implicitly as described in 1.5.2.1.1.1 below. In thiscase, activation and operation of the service are indistinguishable.
Procedures for call establishment are described in PHS MoU specification B-IF1.01[2] with thefollowing modifications. On call request, the SETUP message sent by the calling PS shallcontain independent PHS-UUS service 1, 2 and 3 requests.
The SETUP message sent by the Public CS towards the called PS shall also contain the same
independent service requests. If the called PS can support the indicated PHS-UUS services
requested by the explicit mechanism, then specific service acceptances shall be indicated in theappropriate 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.

12

B-IF1.51-02-TS

1.5.2 Invocation and operation
Note: CAUSE Value Descriptions:
In this subcrause, CAUSE value is indicated as unique style as [xy(hex:bit8=1)]. This
description style is based on PHS MoU specification IF1.01 (refer to 4.4.3.7.3.5.10/BIF1.01).
The cause value is devided into 2parts: Extension bit (bit8 value is always “1”), the classtype value (bits7-5) and reason type value (bits4-1).
[xy(hex:bit8=1)]: x is indicated as hexvalue of extension bit and class type value.
y is indicated as hex value of reason type value.
(hex:bit8=1) indicate the extension bit value as reference.

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 elementof variable length as specified in Annex A/B-IF1.01[2] in the SETUP message, transferred
across the public CS-PS interface at the calling side as described in B-IF1.01[2]. This
information element is transported by the PHS network and delivered unchanged in theUser-user information element included in the SETUP message transferred across the PS-Public
CS interface at the called side as described in B-IF1.01[2]. For activation purposes, thisinformation element must be at least three octets long, as defined in Annex A/B-IF1.51.
A User-user information element may be included in the ALERTing and/or CONNect messages
transferred across the public CS-PS in the interface at the called side as described in BIF1.01[2]. 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 PHS network anddelivered in the User-user information element included in the corresponding message(s)transferred across the user-network interface at the calling side as described in B-IF1.01[2].
1.5.2.1.1.2 Explicit operation (preferred or required)Procedures for call establishment are as described in B-IF1.01[2] and 1.5.2.1.1.1 above, withthe following modifications.

B-IF1.51-02-TS

13

On call request, the SETUP message sent by the calling PS shall contain an explicit PHS-UUS
service 1 request. The SETUP message sent by the Public CS at the called side shall also
contain an explicit PHS-UUS service 1 request. The SETUP message sent by the calling PS
may contain a User-user information element. The SETUP message sent by the Public CS at thecalled side shall also contain a User-user information element if present in the SETUP message
sent by the calling user.
If the called PS can support the transfer of User-user information elements in call establishment
and clearing messages, a PHS-UUS 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 PHS network to thecalling PS in the ALERTing, CONNect or DISConnect message.
A User-user information element may be included in the ALERTing message and/or CONNectmessage transferred across the PS-Public CS interface at the called side as described in BIF1.01[2].
1.5.2.1.2 Call clearing phase
A User-user information element may be included in the first message used to initiate thenormal call clearing phase (see B-IF1.01[2]).
The information contained in such an information element is transferred to the remote PS in thefirst clearing message (see B-IF1.01[2]). Such a transfer is only performed if the information isreceived at the local exchange of the remote PS before sending a clearing message to that PS;
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
the called PS during call establishment at the destination interface.
If the called PS rejects the call with a clearing message containing a User-user information
element, the PHS network shall deliver the User-user information element in the DISConnect
message sent to the calling PS. However, if the PHS network is providing in-band information
to the calling PS, and chooses not to initiate clearing procedures at that time, the PHS network
may deliver the User-user information element in a PROGress message sent to the calling PS.
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[7].
1.5.2.1.3 Actions at the transit exchange
Not applicable to PHS MoU specification B-IF1.51.

14

B-IF1.51-02-TS

1.5.2.1.4 Exceptional procedures
1.5.2.1.4.1 Rejection of implicit service requests

The User-user information element is not transferred to the called PS from the callinguser(PS) who had not suscribed to the PHS UUS service 1. Because such as User-user
information element will be discarded in the PHS network. If the discard occurs, thePHS network shall continue to process the call request. The calling PS will receive theindication that the UUS request is not accepted by way of the sending a STATUS
message containing cause [B2(hex:bit8=1)], “Requested facility not subscribed”, orcause [AB(hex:bit8=1)], “Access information discarded”. The called PS may not be able
to interpret incoming User-user information elements. In such situations, the PS should
discard this information without disrupting normal call handling. No specific signallingis provided by the Public CS to accommodate this situation.
1.5.2.1.4.2 Rejection of explicit service requests
General exceptional procedures are described in B-IF1.01[2] and specific exceptional
procedures are described below.
If the PHS network cannot support PHS-UUS service 1, or the calling user has not subscribedto the service, and it was requested as preferred, a PHS-UUS service 1 rejection indicating“Rejected by network” is included in the CALL PROCeeding, PROGress, ALERTing or
CONNect message, depending on the state of the call at the time that the PHS network
determines that it cannot support the service.
If the service 1 request indicated required and the PHS network 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[AF(hex:bit8=1)] “Resource unavailable, unspecified” or cause [C5(hex:bit8=1)] “Requested
facility not implemented” and a service 1 rejection indicating “Rejected by network”.
If the service 1 request indicated required and the calling user has not subscribed to the service,a DISConnect or RELease COMPlete message is sent with cause [B2(hex:bit8=1)] “Requested
facility not subscribed” and a PHS-UUS service 1 rejection indicating “Rejected by network”.
If the called PS receives a PHS-UUS service 1 rejection,, and the service 1 was requested as
preferred, the rejection indicating “Rejected by user” is included ina)the ALERTing or CONNect message;b)

the first clearing messages prior to the active state.

This explicit service 1 rejection shall be forwarded by the PHS network to the calling PS in the
ALERTing or CONNect message and may be forwarded in the DISConnect message.

B-IF1.51-02-TS

15

If the called PS receives a PHS-UUS service 1 rejection,, and the service 1 was requested as
required, the srejection indicating “Rejected by user” is included in a DISConnect or RELease
COMPlete message with cause [C5(hex:bit8=1)] “Requested facility not implemented”. Thisexplicit service 1 rejection may be forwarded by the PHS network to the calling PS in the
DISConnect message.
If the called PS does not include a PHS-UUS service 1 acceptance or rejection in the
ALERTing, CONNect, DISConnect or RELease COMPlete message, and the service 1 request
indicated preferred, the PHS network shall return an explicit rejection indicating “Rejected byuser” in the CONNect or DISConnect message sent to the calling PS.
If the called PS does not include a PHS-UUS service 1 acceptance or rejection in the
ALERTing or CONNect message, and the service 1 request indicated required, the PHS
network shall clear the call by sending a DISConnect message to the calling PS with cause[C5(hex:bit8=1)] “Requested facility not implemented” and a PHS-UUS service 1 rejection
indicating “Rejected by user”. Furthermore, a DISConnect message with cause[9F(hex:bit8=1)] “Normal, unspecified” shall be sent to the called PS.
If the called PS does not include a PHS-UUS service 1 acceptance or rejection in the
DISConnect or RELease COMPlete message, and the service 1 request indicated required, thePHS network shall include a PHS-UUS service 1 rejection indicating “Rejected by user” in the
DISConnect message sent to the calling PS.
1.5.2.1.4.3

Unexpected User-user information element in call control messages

The User-user information element in ALERTing or CONNect message from called PS will bediscarded in the PHS network,, if there was not the indication, either explicitly or implicitly, of
PHS UUS request in the SETUP message to called PS from the PHS network via the public CS
before. If the discard is occurred, the called PS will receive the cause of the discard as cause[AB(hex:bit8=1)], “Access information discarded” in the STATUS message from PHS network
via public PS.
The User -user information element in DISConnect, RELease and COMPlete message fromneither PSs will also discarded in the PHS network, if there was not the indication, either
explicitly or implicitly, of PHS UUS request in the SETUP message to called PS from the PHS
network via the public CS before. If the clearing party has sent a DISConnect (or RELease)message, the Public CS shall send to the clearing party a RELease (or RELease COMPlete)message containing cause [AB(hex:bit8=1)], “Access information discarded”. If the clearing
party had sent a RELease COMPlete message, the PHS network shall consider the call ascleared to that party; no additional action shall be taken.
The PHS network shall discard the User-user information element if it is received from thecalled PS in the ALERTing or CONNect message, but a request for PHS-UUS was notindicated (either explicitly or implicitly) in the SETUP message delivered to the called PS. If
discard occurs, the PHS network shall take action on the remaining contents of the message

16

B-IF1.51-02-TS

received from the calling PS and shall send a STATUS message to the called PS containing
cause [AB(hex:bit8=1)], “Access information discarded”.
The PHS network shall discard the User-user information element if it is received from either
PS in a DISConnect, RELease or RELease COMPlete message, but a request for PHS-UUS was
not indicated in the SETUP message delivered to the called PS. If discard occurs, the PHS
network shall take action on the remaining contents of the message received from the PS. If theclearing party has sent a DISConnect (or RELease) message, the Public CS shall send to theclearing party a RELease (or RELease COMPlete) message containing cause [AB(hex:bit8=1)],“Access information discarded”. If the clearing party had sent a RELease COMPlete message,
the PHS network shall consider the call as cleared to that party; no additional action shall betaken.
The User-user information element will be discarded by PHS network 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 PHS network receives a message containing the User-user information
element, but that message is not allowed to contain PHS-UUS as defined by thisdocument.

If discard occurs, the PHS network shall take action on the remaining contents of the message
received from the sending PS and shall send a STATUS message to that PS containing cause[AB(hex:bit8=1)], “Access information discarded”. However, if the PHS network discards aUser-user information element from a received clearing message, the PHS network shall
include cause [AB(hex:bit8=1)], “Access information discarded”, in the next sequential
clearing message sent to the PS as specified in B-IF1.01[2]. If the PHS network discards aUser-user information element from a RELease COMPlete message, the PHS network shallconsider the call as cleared to that party; no additional action shall be taken.
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 PS shall contain an explicit PHS-UUS
service 2 request. The SETUP message sent by the PS at the called side, shall also contain an
explicit PHS-UUS service 2 request.

B-IF1.51-02-TS

17

If the called PS can support USER INFORMATION messages during call establishment, a
PHS-UUS service 2 acceptance shall be included in the ALERTing message sent to the PS.
This explicit acceptance indication shall be forwarded in the ALERTing message sent by the
PS to the calling PS .
1.5.2.2.2 Actions at the transit exchange
Not applicable to B-IF1.51.
1.5.2.2.3 Transfer of USER INFORMATION messages
Once an ALERTing message has been received, both the involved PS can transfer information
between themselves by transferring USER INFORMATION messages across the public CS-PS
interface. The PHS network provides for the transfer of such messages from the calling to thecalled side and vice versa. The USER INFORMATION message included the call reference,the protocol discriminator, and the User-user information element as defined in Annex A
in†this B-IF2.51[8]. The More data information element may also be included by the source
user to indicate to the remote user 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 PHS network.
When PHS-UUS service 2 is provided, no more than two USER INFORMATION messages
may be transferred in each direction after the ALERTing message and before the CONNectmessage.
As a network option, USER INFORMATION messages may be transferred to the called PS 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 B-IF1.01[2] and specific exceptional
procedures are described below.
If the PHS network cannot support PHS-UUS service 2, or the calling user has not subscribedto the service, and it was requested as preferred, a PHS-UUS service 2 rejection indicatingìRejected by networkî is included in a CALL PROCeeding, PROGress or ALERTing message,
depending on the state of the call at the time that PHS network determines that it cannot support
the service.
If the PHS-UUS service 2 request indicated required and the PHS network 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

18

B-IF1.51-02-TS

cause [BF(hex:bit8=1)], ìService or option not available, unspecifiedî, or cause[C5(hex:bit8=1)], ìRequested facility not implementedî, and a PHS-UUS service 2 rejection
indicating ìRejected by networkî.
If the PHS-UUS service 2 request indicated required and the calling user has not subscribed tothe service, a DISConnect or RELease COMPlete message is sent with cause [B2(hex:bit8=1)],ìRequested facility not subscribedî, and a PHS-UUS service 2 rejection indicating ìRejected by
networkî.
If the called PS 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 PHS network to
the calling PS in the ALERTing message.
If the called PS 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 [C5(hex:bit8=1)], ìRequested facility not
implementedî. This explicit PHS-UUS service 2 rejection may be forwarded by the Public CS
to the calling PS user in the DISConnect message.
If the called PS does not include a PHS-UUS service 2 acceptance or rejection in the
ALERTing message or a rejection in the DISConnect or RELease COMPlete message and therequest indicated preferred, the PHS network shall return an explicit rejection indicatingìRejected by userî in the ALERTing or DISConnect message sent to the calling PS.
If the called PS does not include a PHS-UUS service 2 acceptance or rejection in the
ALERTing message and the request indicated required, the PHS network shall clear the call bysending a DISConnect message to the calling PS with cause†[C5(hex:bit8=1)], ìRequested
facility not implementedî, and a PHS-UUS service 2 rejection indicating ìRejected by userî.
Furthermore, a DISConnect message with cause [9F(hex:bit8=1)], ìNormal, unspecifiedî, shallbe sent to the called PS.
If the called PS does not include a PHS-UUS service 2 rejection in the DISConnect or RELease
COMPlete message and the request indicated required, the PHS network shall include a PHSUUS service 2 rejection indicating ìRejected by userî in the DISConnect message with cause[9F(hex:bit8=1)], ìNormal, unspecifiedî, shall be sent to the calling PS.
1.5.2.2.4.2 Excess USER INFORMATION messages
In the following cases, the PHS network shall discard the USER INFORMATION message andsend a STATUS message with cause [AB(hex:bit8=1)], ìAccess information discardedî, to thesending PS :
ñ if the PHS network receives a USER INFORMATION message in the alerting phase, but
PHS-UUS service 2 is not activated;

B-IF1.51-02-TS

19

ñ if the PHS network receives more than two USER INFORMATION messages from a PS;ñ if the PHS network receives a USER INFORMATION message in any other call phasethan the alerting 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 PS shall contain an explicit PHS-UUS
service 3 request. The SETUP message sent by the Public CS at the called side shall also
contain an explicit PHS-UUS service 3 request.
If the called PS 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 PS may request PHS-UUS service 3 preferred only. A
FACility message indicating a PHS-UUS service†3 request is sent from the requesting PS to the
PHS network. The PHS network shall indicate the PHS-UUS service 3 request to the PS that
did not request PHS-UUS service 3 in the FACility message and start timer T1 at the public
CS-PS interface of the requesting PS.
If the PS 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 returnedin the FACility message. This explicit acceptance is conveyed back to the requesting PS in a
FACility message and the PHS network shall stop timer T1.
1.5.2.3.3 Actions at the transit exchange
Not applicable to B-IF1.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 PS may transfer
information to the other by conveying USER INFORMATION messages across the PS - Public
CS interface. The PHS network provides for the transport of such messages. The USERINFORMATION 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
PS to indicate to the remote PS 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 PHS network; in particular, integrity of blocks fragmented
using this procedure is not guaranteed.

20

B-IF1.51-02-TS

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 torestrict USER INFORMATION message flow in each direction.
In each direction a burst capability of sending N USER INFORMATION messages shallimmediately be available to each PS , where N initially equals the value of the burst parameter
X. The value of N shall be decremented by one for every USER INFORMATION message sentby the PS and incremented by Y at regular intervals of T subject to the limitation that N shallnot exceed X.
The burst parameter X shall be set to a value of X = 16 and the replenishment parameter Y shallbe set to Y = 8.
NOTE ñ While some PHS networks 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 PHS network using higher
values to take the appropriate actions, unless bilateral agreements exist.
If the PHS network within the period T receives more than N USER INFORMATION
messages, the excess message(s) shall be discarded. The PHS network 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 [AB(hex:bit8=1)], ìAccess information discardedî. Subsequent
received USER INFORMATION messages shall be discarded by the Public CS without any
indication to the PS.
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 CONGESTIONCONTROL message indicating ìReceive readyî shall be sent to the PS. If no USERINFORMATION has been discarded, no indication shall be sent. The PS cannot flow control
USER INFORMATION messages received from the PHS network .
If the PHS network receives a CONGESTION CONTROL message from the PS, a STATUS
message with causes [EF(hex:bit8=1)] ìProtocol error, unspecifiedî shall be sent to the PS andno 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 B-IF1.01 and specific exceptional proceduresare described below.
If the PHS network cannot support PHS-UUS service 3, or the calling user has not subscribedto the service, and it was requested as preferred, a PHS-UUS service 3 rejection indicatingìRejected by networkî is included in a CALL PROCeeding, PROGress, ALERTing or

B-IF1.51-02-TS

21

CONNect message, depending on the state of the call at the time that the PHS network
determines that it cannot support the service.
If the PHS-UUS service 3 request indicated required and the PHS network 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 withcause [AF(hex:bit8=1)] “Resource unavailable, unspecifiedî or cause [C5(hex:bit8=1)]ìRequested facility not implementedî, and a PHS-UUS service 3 rejection indicating ìRejectedby networkî.
If the PHS-UUS service 3 request indicated required and the calling user has not subscribed tothe service, a DISConnect or RELease COMPlete message is sent with cause [B2(hex:bit8=1)]ìRequested facility not subscribedî, and a PHS-UUS service 3 rejection indicating ìRejected by
networkî.
If the called PS 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 CONNectmessage. This explicit PHS-UUS service 3 rejection shall be forwarded by the PHS network to
the calling PS in the CONNect message.
If the called PS 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 [C5(hex:bit8=1)] ìRequested facility not
implementedî. This explicit PHS-UUS service 3 rejection may be forwarded by the PHS
network to the calling PS in the DISConnect message.
If the called PS does not include a PHS-UUS service 3 acceptance or rejection in the CONNectmessage or a rejection in the DISConnect or RELease COMPlete message and the request
indicated preferred, the PHS network shall return an explicit rejection indicating ìRejected byuserî in the CONNect or DISConnect message sent to the calling PS.
If the called PS does not include a PHS-UUS service 3 acceptance or rejection in the CONNectmessage and request indicated required, the PHS network shall clear the call by sending a
DISConnect message to the calling PS with cause [C5(hex:bit8=1)] ìRequested facility not
implementedî, and PHS-UUS service 3 rejection indicating ìRejected by userî. Furthermore, a
DISConnect message with cause [9F(hex:bit8=1)], ìNormal, unspecifiedî, shall be sent to thecalled PS.
If the called PS does not include a PHS-UUS service 3 rejection indicating ìRejected by userî inthe DISConnect or RELease COMPlete message and the request indicated required, the PHS
network shall include a PHS-UUS service 3 rejection in the DISConnect message sent to thecalling PS.
1.5.2.3.6.2 Rejection of service requested after call establishment
General exceptional procedures are described in B-IF1.01 and specific exceptional procedures

22

B-IF1.51-02-TS

are described below.
If the PHS network cannot support PHS-UUS service 3, or the requesting user has no
subscribed to the service, a PHS-UUS service 3 rejection indicating ìRejected by networkî is
included in a FACility message.
If the PS did not request PHS-UUS service 3 at receives a PHS-UUS service 3 rejection, a PHSUUS service 3 rejection indicating ìRejected by userî shall be returned in the FACility message
and stop timer T1.
If the requested PS does not respond to the PHS-UUS service 3 request before timer T1 expires,
the PHS network shall return a PHS-UUS service†3 rejection indicating ìRejected by userî to
the requesting PS.
Collision of requests for PHS-UUS service 3 occurs when there is an outstanding request for
PHS-UUS service†3 and a subsequent request is received from the called PS. In this situation,
the entities (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 PS anda) it is not allowed in the current call state (e.g. in any other state than active where only
PHS-UUS service 3 is activated); and/orb) the appropriate PHS-UUS service has not been activated,the message shall be discarded by the PHS network. The public CS shall also send a
STATUS message with a cause [AB(hex:bit8=1)] ìAccess information discardedî.

B-IF1.51-02-TS

23

Annex A
Necessary additional Informations to B-IF1.01(This annex forms an integral part of this specification)
This annex describes the necessary additional informstions required in B-IF1.01 for theoperation of PHS-UUS supplementary service.
A.1 Congestion level
The purpose of the Congestion level information element is to describe the congestion status of
the call. It is a single octet information element coded as shown in Figure A-1/B-IF1.51 andTable A-1/B-IF1.51.

Bits
8

7

6

5

4

3

2

1

Octet

Congestion level
1

0

1

1

Congestion level

Information element
identifier

Figure A-1/B-IF1.51
Congestion level information element

Table A-1/B-IF1.51
Congestion level infomation element coding

Congestion level (octet 1)
Bits
4 3 2 10 0 0 01 1 1 1

receiver readyreceiver not readyAll other values are reserved.

24

B-IF1.51-02-TS

1

A.2 More data
The More data information element is sent by the personal station to the public cell station in a
USER INFORMATION message, and delivered by the PHS network to the destination personal
station in the corresponding USER INFORMATION message. The presence of the More data
information element indicates to the destination personal station that another USERINFORMATION message will follow, containing information belonging to the same block.
The use of the More data information element is not supervised by the ISDN.
The More data information element is coded as shown in Figure A-2/B-IF1.51.
The length of this information element is one octet.

8

7

6

5

4

3

2

1

Octet

0

0

0

1

More data
1

0

1

0

0

Information element identifier

Figure A-2/IF1.51
More data information element

B-IF1.51-02-TS

25

A.3

User-user

The purpose of the User-user information element is to convey information between personal
stations. This information is not interpreted by the PHS network, but rather is carriedtransparently and delivered to the remote personal station.
The User-user information element is coded as shown in Figure A-3/B-IF1.51 and Table†A2/B-IF1.51. There are no restrictions on content of the user information field.
In ALERTING, CONNect, DISConnect, RELease and RELease COMPlete messages, the Useruser information element has a maximum size of 131 octets.
In USER INFORMATION messages sent in association with a circuit-mode connection, theUser-user information element has a maximum size of 131 octets.
NOTE ñ The User-user information element is transported transparently by an PHS
network between a call originating entity, e.g.†a calling user and the addressed entity,e.g. a remote user or a high layer function network node addressed by the calloriginating entity

Bits
8

7

6

5

4

3

2

1

Octets1

1

0

1

User-user
0

1

1

1

1

Information element identifier
Length of user-user contents

2

Protocol discriminator

3

User information

4
etc.

Figure A-3/B-IF1.51
User-user information element26

B-IF1.51-02-TS

Table A-2/IF1.51
User-user information element
Protocol discriminator (octet 3)
Bits
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1
0 0 0 0 0 0 1 0
0 0 0 0 0 0 1 1
0 0 0 0 0 1 0 0
0 0 0 0 0 1 0 1
0 0 0 0 0 1 1 1
0 0 0 0 1 0 0 0

User-specific protocol (Note 1)
OSI high layer protocols
X.244 [9] (Note 2)
Reserved for system management convergence function
IA5 characters (Note 4)
X.208 and X.209 coded user information (Note 5)
Rec. V.120 [10] rate adaption
Q.931/I.451 user-network call control messages

0 0 0 1 0 0 0 0
through 0 0 1 1 1 1 1 1}

Reserved for other network layer or layer 3 protocols,
Including Recommendation X.25 [11] (Note 3)

0 1 0 0 0 0 0 0
through 0 1 0 0 1 1 1 1}

National use.

through 0 1 0 1 0 0 0 0
1 1 1 1 1 1 1 0}

Reserved for other network layer or layer 3
Protocols, including Recommendation X.25 (Note 3)

All other values are reserved.
NOTES
1
The user information is structured according to user needs.
2
The user information is structured according to Recommendation X.244 which
specifies the structure of†X.25 call user data.
3
These values are reserved to discriminate these protocol discriminators fromthe first octet of a Recommendation X.25 packet including general format
identifier.
4
The user information consists of IA5 characters.
5
The number of X.208 and X.209 components contained in a User-user
information element as well as their semantics and use are user-application
dependent and may be subject to other Recommendations.

B-IF1.51-02-TS

27

A.4 Message typeThis section shows the message types which are added for controlling the PHS UUS. Refer to
B-IF1.01 for other message types and notes if necessary.

Bit
8 7 6 5 4 3 2 1
0 0 1 - - - - 0 0 0 0 0Call information phase message
SER INFORMATION

0 1 1 - - - - 1 1 0 0 1

Other message
ONGESTION CONTROL

Figure A-4/B-IF1.51
A.5 Information element codingThis section shows the information elements which are added for controlling the PHS UUS.
Refer to B-IF1.01 for other message types and notes if necessary.
[Codeste 0]Bit
8 7 6 5 4
1 - - - 0 1 0 0
0 1 1 -

3
0
-

2
0
-

1
0
-

0 - - - - - - 1 1 1 1 1 1 1Single octet information element
More data
Congestion level
Multiple octet information element
User-User

Figure A-5/B-IF1.51

28

B-IF1.51-02-TS

Reference[1]

ARIB standard RCR STD-28 Personal Handy Phone System.

[2]

PHS MoU Document B-IF 1.01 Public Personal Handy-Phone System: Specifications ofInterface between Personal Station and Public Cell Station (Common Air Interface).

[3]

PHS MoU Document B-NW0.00 Public Personal Handy-Phone System: Network and
System Configurations.

[4]

PHS MoU Document B-SV 2.7 Public Personal Handy-Phone System: Service
Specification of PHS User-to-user Signalling.

[5]

PHS MoU Document B-IF 2.02 Public Personal Handy-Phone System: Interface between
Public Cell Station and ISDN-based PHS Switching Center-Layer 3 Specification.

[6]

CCITT Recommendation Network service definition for Open System Interconnection(OSI) for CCITT applications, Rec. X.213.

[7]

ISO 8348:1988 Information processing systems - Data communications – Network
service definition.

[8]

PHS MoU Document B-IF2.51 Public Personal Handy-Phone System: Public Cell Station– ISDN Interface – PHS-UUS Supplementary service –[9]

CCITT Recommendation Procedure for exchange of protocol identification during virtual
call establishment on packet switched public data networks, Rec. X.244.

[10] CCITT Recommendation Support by an ISDN of data terminal equipment with V-Series
type interface with provision for statistical multiplexing, Rec. V.120.
[11] CCITT Recommendation Interface between data terminal equipment(DTE) and data
circuit terminating equipment(DCE) for terminals operating in the packet mode andconnected to public data networks by dedicated circuit, Rec. X.25.

B-IF1.51-02-TS

29