«ETSI TR 102 021-2 V1.3.1 (2010-12) Technical Report Terrestrial Trunked Radio (TETRA); User Requirement Specification TETRA Release 2.1; Part 2: High ...»
It is assumed that for Release 2.1 it will be enough if the "point" in a point-to-multipoint data session is either a radio or fixed terminal and that role will remain throughout the session, i.e. the session is set up with one participant in a special role compared to the other attendees. Future releases may require full group voice call type of functionality where any party in the group can be the originator and everyone will receive what is being sent.
The membership of a point-to-multipoint data group should be easily manageable in a similar type of manner as talk group memberships are managed in current TETRA systems. This should include both controlling which subscriber can be a member of a group and joining/leaving the group in daily operation, initiated by the user or some controlling entity.
However, although management actions similar to those used with talk groups are required, the data groups should not be limited to or automatically linked to voice talk groups.
A typical session could consist of the "point" sending information, e.g. a picture with accompanying textual data or live video, to the other members of this data session. They might not communicate within this session except possibly by positive or negative acknowledgement, i.e. all information received or not.
Several of the application types mentioned in clause 4.2.1 could be used in point-to-multipoint manner.
4.2.3 Voice over HSD Although not seen as one of the first applications to use HSD technology, it is expected that carrying voice over the same channels as used to carry the fast non-voice applications is likely to be of interest to some operators in the future.
The new modulation methods could provide a flexible voice capacity solution providing more capacity near the base station, which typically is a higher user density area than the edge of the cell where the available bit speeds would in turn be lower. The benefits would be most applicable in traffic hotspots like major cities where the area covered by an average TETRA cell is relatively small.
Utilising direct access and avoiding the TETRA 1 carriers completely might provide another incentive for the operator to consider voice over HSD.
Even if new services or codec(s) would be implemented for voice over HSD, for backwards compatibility and migration from TETRA 1 the same voice functionality and codec as provided by TETRA 1 should be maintained, unless an practically instantaneous translation to and from TETRA 1 codec is implemented.
4.3 Data rate capacity in addition to TETRA V+D Analysis of the non-voice application requirements listed in table 1 has identified that the new HSD service will have very little impact in reducing voice traffic levels in TETRA networks. For this reason, the provision of HSD on existing networks will require separate capacity to support non-voice applications dependent on type of applications, levels of traffic and GoS.
Based on past experience, the types of non-voice applications, traffic levels and GoS will vary greatly between different user organizations. As a result, some organizations will have a low demand for HSD services and others a high demand.
For these reasons, the HSD technology solution should be designed to support varying amounts of data as spectrum efficient as possible balanced against technology constraints. In addition, the HSD solution should be such as to minimize impact on network RF planning and compatibility with TETRA Release 1 networks already deployed and/or being deployed.
In the 2007 workshop [i.2] the overall highest ranking area of improvement for developing TETRA beyond Release 2 was to increase the speed, capacity, and efficiency of TEDS (as specified for Release 2). When the results were analysed based on the background of the responders, this area scored highest in four out of six groups, whilst being second for the remaining two groups.
There is a clear expectation that the data speed needs will grow past what Release 2 can deliver and Release 2.1 should aim to fulfil that need. Very little real data on the professional data use exists at the time of writing, but it is believed that the actual need for capacity will come from a combination of new essential and potentially bandwidth hungry applications and wide use of them, i.e. although requirements placed by a single application possibly could be fulfilled by Release 2 HSD, the network could not support the numbers of users without having a faster HSD service.
Release 2 HSD provides a good high speed data solution for many TETRA users. For those users that require more Release 2.1 should introduce a significant improvement in the HSD service in terms of speed, capacity and efficiency.
A small improvement is not likely to justify the extra investment required by both manufacturers and users. Another reason to clearly exceed Release 2 HSD capabilities is to be able to convincingly compete against using alternative services, e.g. commercial mainstream mobile networks.
4.4 RF coverage requirements for HSD The coverage of HSD service should match that of TETRA Release 1 for Voice and Data as evidenced by the 2007 workshop where this was considered the most important TMO enhancement area [i.2]. Exact user requirements of RF coverage needs for HSD applications vary greatly between different user organizations. For example, some users want total RF coverage, others would trade off data rate as distance increases from the base station and others would be satisfied with only urban (high population density) coverage. Solutions that rely on e.g. special fill-in cells for the (very) high speed data service could potentially be accepted.
Based on these user requirements, the HSD technology solution adopted should consider a mechanism for meeting these varying needs.
4.5 Frequency spectrum efficiency requirements As mentioned in clause 4.3, analysis of non-voice applications identified that the new HSD service will have very little impact in reducing voice traffic levels in TETRA networks. For this reason, if the Grade of Service for voice services is to remain unchanged, the provision of HSD on existing networks will require additional frequency spectrum to support non-voice applications dependent on type of applications, levels of traffic and GoS. Alternatively, HSD services may be introduced by reducing the Grade of Service of existing voice services and hence freeing network capacity to maximize user benefits within existing network resources. This will not be acceptable to all users.
ETSI 12 ETSI TR 102 021-2 V1.3.1 (2010-12) Also, as mentioned in clause 4.3, the demand for non-voice applications will vary greatly between different user organizations. For these reasons, the HSD service should utilize the minimum amount of RF spectrum required to meet the non-voice application, capacity and GoS needs of individual user organizations.
In addition, there is a need to retain the narrow band characteristics of TETRA for co-existence with other TETRA V+D networks and other narrow band technologies sharing the same frequency bands.
In areas where an effective modulation scheme can be used, moving voice traffic to be carried over TEDS in a capacity optimized manner could possibly enable more real payload per kHz than using a combination of TETRA 1 for voice and HSD for non-voice data, improving the spectrum efficiency of the TETRA solution in urban areas and other traffic hot spots where the cell sizes are relatively small.
For the reasons above, the HSD technology solution should consider a design that provides flexibility to meet these requirements.
4.6 Integration of HSD with TETRA Release 1 V+D services The 2001 user requirements for HSD services are marked by a strong need for integration with the V+D services of TETRA Release 1. The degree of integration varies from very high for simultaneous Voice and HSD operation, to moderate and low respectively for voice communication priority over HSD to independent operation of Voice and HSD.
These respective user integration requirements for all markets combined are listed in table 2.
As well as the importance weighting for each criteria, a column showing the Minimum (Min) and Maximum (Max) weighting from the respondents is provided.
As these integration requirements will vary between user organizations, the implementation of HSD should be such as to support all three requirements.
NOTE 1: It is expected that the extent of service interaction requirements will be considered by ongoing work within WG1. For example further work may be required to confirm that simultaneous voice and HSD within TETRA Release 2 should have the same meaning as simultaneous Voice and Data within TETRA Release 1.
NOTE 2: Standardisation of High Speed Data using a multicarrier solution on different bandwidths has made simultaneous Voice using TETRA Release 1 air interface and high speed Data complicated due to the group communication.
NOTE 3: An approach for simultaneous voice and HSD could be using the high speed data modulation also for voice.
4.7 Compatibility of HSD with TETRA Release 1 V+D services Although outside the scope of the TETRA Release 2 Questionnaire, it has been requested by WG4 to consider the following three aspects as part of the HSD URS where HSD needs to be compatible with TETRA Release 1 as near as
practically possible. These three areas are:
• VoIP or some other transportation method for voice.
• Network data interface.
Although the internal aspects of a SwMI are not in the scope of any TETRA standard (except for external interfaces), consideration should be given in the HSD technology solution as to the impact to VoIP networks in terms of GoS and data capacity provision within the SwMI. If VoIP solution is applied, then the voice coding should be the same as is TETRA Release 1 in order to preserve voice quality and to support end-to-end encryption. VoIP may not provide a good solution at the air interface due to high overhead and some other solutions may need to be studied.
With regard to network data interfaces, consideration should be given in the HSD technology solution as to the variety of interfaces that would need to be supported for HSD. The main data interface is considered to be Internet Protocol and interfaces implemented e.g. in public networks should be supported.
With regard to the velocity of MS units, it is important that the HSD technology solution should not greatly differ in performance from that already offered in TETRA Release 1.
In addition to the above, it is important that the HSD technology solution should not degrade the performance of any TETRA Release 1 network and should be compliant with the TETRA Release 1 standard and TETRA Interoperability Profiles (TIPs) where applicable.
4.8 HSD call types The user requirement for HSD call types has many variants within the "one to one" and "one to many" categories. The communications matrix in table 3 shows the variety of call types required for HSD.
Based on this requirement, the HSD technology solution should support both "one to one" and "one to many" call types from both MS and fixed users within a TETRA network and from user operating in externally connected networks. For data "one to many" can be broadcast type unidirectional communication.
4.9 Backward compatibility with TETRA Release 1 For reasons of evolution and utilization of TETRA Release 1 services, a TETRA Release 2 network provisioned with conventional access HSD should support TETRA Release 1 terminals while not causing any degradation of services, facilities and operational performance to TETRA Release 2 terminals on the network.
Likewise a TETRA Release 1 network should support TETRA Release 2 terminals provisioned with Release 2 conventional access HSD while not causing any degradation of services, facilities and operational performance to TETRA Release 1 terminals on the network.
A network supporting TETRA Release 2.1 direct access HSD may but does not need to support TETRA 1 services.
It has been identified that there can be three different types of terminals in TETRA networks:
• TETRA terminal supporting Release 1;
• TETRA terminal supporting Release 2 and/or Release 2.1 HSD;
• TETRA terminal supporting Release 1 and at least one version of HSD (Release 2 conventional access HSD and/or Release 2.1 direct access HSD).
TETRA systems and base stations may provide:
• TETRA Release 1 Voice and Data services;
• TETRA Release 2.x HSD services;
• TETRA Release 1 Voice and Release 2.x HSD services.
In the above lists Voice service means TETRA Release 1 air interface and voice codec. Voice service for high speed data is not yet defined.
TETRA services evolution and user needs indicate that voice service will be important to most of the users and a transparent (bit exact) TETRA coded voice transport is essential, when voice service is used. Support of the TETRA Release 1 air interface may be less important in long term.
Some users need high speed data for their service and may not need voice at all in the same equipment that is optimized for data services. These equipment may be simple to implement, if they can access services without TETRA Release 1 control channels. These equipment are called direct access terminals.
The principal objective of Release 2.1 direct access HSD is to provide more efficient packet data TEDS systems.
• A direct access system does not need the 25 kHz TETRA 1 MCCH. This avoids the need to provide a set of 25 kHz channels in a direct access network which may be in a different frequency band from any existing TETRA 1 network. This should result in lower system cost and easier spectrum allocation for data-only direct access networks.
Other advantages that arise from direct access include:
• (Where the TETRA 1 MCCH is retained) Potentially reduces the load on the TETRA 1 MCCH because MSs can move to TEDS channels without TETRA 1 MCCH signalling (i.e. direct access MSs do not make random access attempts on the TETRA 1 MCCH).
• Mobility based on C/I instead of RSSI becomes possible. This could provide greater immunity to interference and jamming. It could also give better frequency re-use.
• Additional "fill-in" TEDS cells to supplement coverage and capacity for the TEDS service where the TETRA 1 service is adequate.
The direct access method can continue to use the security and much of the signalling already designed for TETRA.
TETRA direct access allows additional TEDS cells to be added to a TETRA network without the need for their own TETRA 1 MCCHs, to supplement coverage and capacity, etc. However the packet data channels in such additional direct access cells may not be accessible to an conventional access MS. If there is a general requirement to extend the coverage of QAM packet data channels, other methods may be used that would be accessible by conventional access MSs (e.g. by using sectored channels, as already specified in the standard).
Long-term evolution could lead to provision of all present TETRA services, including individual and group voice calls, over a direct access TEDS system. There would be no requirement for a TETRA 1 MCCH in such a network.
Table 4 is provided to further explain these user requirements.
4.10 Migration from TETRA Release 1 User organizations have expressed a need to utilize HSD services as economically as possible on existing TETRA V+D networks. For this reason, the implementation of HSD should be as economical as possible.
In addition, the field upgrade and provision of HSD on TETRA V+D networks should be carried out with the minimum of disruption to existing communication services.