6.2.1.1 and 6.2.3 and corresponding tests replacements
A document with proposals for new contents in clauses 6.2.1.1, 6.2.3, C.6.2.1.1 and C.6.2.3 is attached.
It is a response on the call for proposals from JTB eAcc for the meeting in 2024-03-14, submitted by EDF, ITS and Deveryware.
It has requirements on RTT communication in 6.2.1.1 subdivided in some required scopes. 6.2.3 on RTT interoperability has a few normative standards just for RTT communication and is also subdivided in the same scopes as 6.2.1.1. An informative set of notes tell how these central RTT standards are included in technology specific standards with wider scopes. Corresponding test clauses are provided with the goal to be possible to perform without intrusion in the systems under test or the test systems, and with the goal to enable the verifications of compliance required from the EAA.
The proposal is made with the following comments and actions in mind referring to the draft version of EN 301 549 from 2024-01-23 in #219, which is also available as N675 related to JTB eAcc.
All resolutions have corresponding texts in the document linked to this issue.
Comment 1
6.2.1.1 Title We propose to make the title more specific, underlining that the clause concerns only basic functionality for RTT communication, i.e. the ability to send and receive text in continuous manner. In the associated tests we for example do not examine display characteristics, that otherwise would be a natural part of concluding whether the service can be qualified as “RTT communication”
Resolution:
Replace “RTT communication” with “RTT basic communication”
Comment 2 6.2.1.1 clause The N675 formulates the requirement for basic RTT communication for ICT in general, but it is hard to formulate the requirements under one clause. It also uses terms like “conversation” and “participant” that remain undefined and are troublesome because they may be erroneously understood/associated with only human-human communication while the requirement should apply also to communications when human communicates with an automated chatbot/agent. As worded in N675 it does not separate the different entities involved in the call, so it is impossible for anyone entity to meet the requirement as worded. This becomes clear when you try to define a test for the requirement because no one entity can test it by itself as worded. It also is not clear with the responsibilities of the dirrerent entities are for doing this. The only way to solve it is to break the requirement into separate provisions, that can each be addressed by single entities. RTT basic communication functionality should be tested in practice, working on the core networks used by the services. This is explicitly required in M/587 Part C, section 2.1, bullet 3.
Resolution
Divide 6.2.1.1 in three scenarios in subclauses, each of which is only required of a single entity able to meet it:
6.2.1.1.1 RTT basic communication between services
6.2.1.1.2 RTT basic communication within a service
6.2.1.1.3 RTT basic communication of voice capable ICT All the subclauses require different scope of interoperability, and therefore RTT functionality can now be tested for each case separately.
Comment 3.
C.6.2.1.1 clause:
The current C.6.2.1.1 test in N675 has two problems: It uses the undefined concept of “reference terminal” It needs to be divided so that each entity can test the part of RTT this entity is responsible for.
Resolution:
The test has been split into multiple parts with each entity is responsible for testing only the part that the entity is responsible for. The proposed test are included in C.6.2.1.1.1, C6.2.1.1.2, and C.6.2.1.1.3 in the enclosed file.
Comment 4:
C.6.2.1.1 clause
The use of the “reference terminal” as the only means to test RTT communication as proposed in the N675 may not be practical because it may not be available. However, as an option it could be accepted. And if available, it would be good. As an alternative a qualified test service could be introduced to facilitate the tests. A qualified test service can facilitate the entities’ ability to demonstrate that RTT functionality is delivered.
Resolution:
An option to use a qualified test service is proposed for doing the testing, but it is not required. The proposed test is included in C.6.2.1.1.1.1 as TEST A in the enclosed file. The proposed qualified test service is using the communication standards that are used in NG112 emergency communications, which many services are required to interoperate with.
Comment 5:
C.6.2.1.1 Clause
The N675 wording does not explicitly identify emergency communication as an important scenario for RTT communication, required by point a(iii) in Section IV of Annex I of the EAA.
Resolution:
A specific test for the RTT basic communication for emergency communication should be included in C.6.2.1.1. The proposed test is included in C.6.2.1.1.1.3 in the enclosed file. Other aspects such as collaboration with relay services may be added in clause C.13.
Comment 6:
C.6.2.1.1 Clause
The N675 wording does not explicitly identify RTT basic communication scenario in roaming conditions. This is explicitly required in M/587 Part C, section 2.1, bullet 3.
Resolution
A specific test for the RTT basic communication in roaming should be included in C.6.2.1.1. The proposed test is included in C.6.2.1.1.1.2 in the enclosed file,
Comment 7
6.2.3 Clause
The different situations where RTT communication can be provided are so different that it is hard to formulate the test requirements under one clause. Entities should have only be responsible for their portion of the system. The N675 wording does not specify normatively kernel RTT standards. This is not meeting the requirements formulated by the EC in M/587.
Resolution:
Divide 6.2.3 in three scenarios in subclauses: Between services, within a service and with ICT These are structured such that they allow both collaboration in conforming and the ability to conform by oneself. The kernel RTT standards for interoperability are normatively referenced, but they are not required when interoperability can be achieved through other means.
The specific formulations are included in 6.2.3.1, 6.2.3.2, and 6.2.3.3 in the enclosed file.
Comment 8
6.2.3 clause
N675 does not address the issue of RTT interoperability with analogue text telephony. Analogue text telephony was included in v3.2.1. normatively. It can be questioned if it should be included or excluded, because it is close to be outdated.
Resolution:
Text telephony is in the attached proposal currently only included as a note (see NOTE 10 in clause 6.2.3.1). Text telephony can provide an RTT-like communication, but not full functionality. It will be expensive and complicated to provide interoperability between modern RTT with legacy text telephony.
It should be discussed if it should be included in the EN.
Comment 9
C.6.2.3 Clause
In N675 the tests require a reference terminal. It can not be guaranteed that one is available, see also comment above.
Resolution:
Change to requiring the claim of use of the standards or declaration of interoperability. Proprietary systems are allowed to create their own RTT specifications for use in their systems. The specific tests are included in C.6.2.3.1, C.6.2.3.2, and C.6.2.3.3 in the enclosed file.