10.13 Analogue FM/TIA-603-D and other legacy LMR interworking

23.2833GPPMission Critical Communication Interworking with Land Mobile Radio SystemsRelease 18TS

10.13.1 General

An IWF representing an LMR user can support interworking with legacy analogue FM radio systems that are compliant with the TIA-603-D [9] Standard. This type of legacy LMR system is sometimes referred to as conventional FM radio.

Characteristics of legacy conventional FM radio include:

– Voice media is conveyed without the use of a voice codec.

– There is no possibility of end-to-end encryption between an LMR user and a MC user.

– Group communication is possible using various means to identify a group such as a single channel / FM frequency, or sub-audible data as defined in [3]. The means for identifying groups within the legacy conventional FM system is outside the scope of the present document.

– The ID of the talking party is generally not available. Various means to identify a talker are available in legacy conventional FM systems, but this is outside the scope of the present document.

– Indication of call priority (e.g. emergency) is generally not available. Various means to identify priority are available in legacy conventional FM systems, but this is outside the scope of the present document.

Other legacy LMR systems such as digital conventional (e.g. P25 conventional), trunked analogue FM systems, non-standard legacy LMR systems, both conventional and trunked, can also be supported as long as they conform to the present document.

10.13.2 Interworking Concepts

Procedures defined in the present document are applicable to interworking with legacy analogue FM radio systems.

Architecture concepts for interworking are summarized below, including general information for other legacy conventional radio systems.

– The IWF is configured with knowledge of groups and users from legacy conventional LMR radio systems. Translations to MCPTT Group and MCPTT User IDs is performed by the IWF as specified in the present document. How the legacy LMR conventional system supports groups, such as mapping a group to a channel/frequency, or using a Group ID (i.e. P25 conventional), or mapping some other protocol element or tone signalling to a group is outside the scope of the present document.

– Interworking to a legacy conventional LMR system can make use of the following procedures as defined in the present document:

– affiliation;

– group management including group regrouping

– group calls including pre-arranged, chat, and broadcast;

– priority calls including emergency and imminent peril; and

– private calls.

NOTE 1: Some analogue FM conventional LMR systems and digital conventional LMR systems support various schemes for private call. These can be supported as long as they conform to the present document.

– Interworking to a legacy conventional LMR system can make use of the following functions of the MCPTT system, as defined in the present document:

– transcoding.

– Interworking to a legacy conventional LMR system can make use of the following functions of the MCPTT system, as defined in the present document, with some limitations:

– caller ID / talker ID;

– priority indication (e.g. emergency);

– end-to-end encryption;

– location; and

– short data service.

NOTE 2: Some digital conventional LMR systems, such as P25 Conventional, natively support group IDs, user IDs, short data, and priority indication. In some cases, the talker ID becomes available sometime after the call starts.

NOTE 3: Some analogue FM conventional LMR systems support various schemes for caller ID, emergency, and other features (e.g. Multi-tone, Type 99). These can be supported as long as they conform to the present document. In some cases, the talker ID becomes available sometime after the call starts.

NOTE 4: Some digital conventional LMR systems, such as P25 Conventional, can support end-to-end encryption between the LMR user and a MC user. There is no possibility of end-to-end encryption between an analogue FM LMR user and a MC user.

10.13.3 Procedures

As described above, existing procedures in this document can be used for interworking with legacy conventional LMR radio systems.

The following procedures describe special cases where the MCPTT ID (i.e. talker ID) is updated during a media transmission within a call. This mechanism of updating the MCPTT ID part way through an MCPTT media transmission may be used for any MCPTT media transmission described elsewhere in the present document.

10.13.3.1 Group call with talker ID update initiated by an LMR user on an interworking group defined in the MCPTT system

In this procedure, an LMR user in a legacy conventional FM radio system initiates a group call on an interworking group defined in the MCPTT system. The talker ID is not known at the start of the call and is updated after media transmission begins. The signalling procedure is described in figure 10.13.3.1-1.

This subclause is based upon subclause for pre-arranged group call setup in 3GPP TS 23.379 [7], subclause 10.6.2.3.1.1.2.

Pre-conditions:

1. The interworking group information is known at the MCPTT server and the IWF by configuration or group creation. The interworking group has been defined in the MCPTT system.

2. MCPTT client 1 and MCPTT client 2 are registered and their respective users are authenticated and authorized to use the MCPTT service.

3. The users in this interworking group have been affiliated to the interworking group.

4. The mapping relationship of group and user identities between the MCPTT system and the LMR system has been configured at the IWF.

5. The LMR user in a legacy conventional FM radio system initiates a group call.

NOTE 1: For all the signalling messages passing through the IWF between the MCPTT system and the LMR system, the IWF performs the identity conversion and protocol translation.

Figure 10.13.3.1-1: Group call with talker ID update initiated by an LMR user on an interworking group defined in the MCPTT system

1. The IWF sends an IWF group call request to the MCPTT server for call establishment. In this case floor control is also requested and an indication of implicit floor request is included. The IWF uses its pre-configured MCPTT ID in the group call request.

2. The MCPTT server calls the affiliated users from the MCPTT system as described in 3GPP TS 23.379 [7]. The LMR user is in a legacy conventional FM radio system so E2EE is not specified, and transcoding is needed at the IWF.

3. If the group has other affiliated LMR users than the calling party and the MCPTT server has received individual affiliations from those LMR users, an individual IWF group call request is sent to the IWF for each affiliated LMR user.

NOTE 2: Steps 2 and 3 can occur in any order.

NOTE 3: How the LMR users from the LMR system are being called is outside the scope of the present document.

4. The IWF returns IWF group call response(s) to the MCPTT server.

5. The MCPTT server confirms the successful establishment of the group call by sending an IWF Group call response to the IWF.

NOTE 4: How the group call response is returned to the initiating LMR user is outside the scope of the present document.

6. The interworking group call has successfully established media plane for communication and any user can transmit media. The MCPTT system where the interworking group is defined is the controlling system of the group call and manages the floor control.

NOTE 5: How the floor control is managed in the LMR system is outside the scope of the present document.

7. Because the group call request contained an imlicit floor request, and no other users are requesting the floor, the MCPTT server sends an IWF floor granted message to the IWF confirming that the IWF has the floor. The MCPTT server also sends Floor taken messages to the affiliated users in the MCPTT system. The MCPTT ID in the floor taken messages is the pre-configured IWF MCPTT ID.

8. If the group has other affiliated LMR users than the calling party, and the MCPTT server has received individual affiliations from those LMR users, an individual IWF floor taken message is sent to the IWF for each affiliated LMR user.

9. At some time after media transfer begins, the IWF receives knowledge of the LMR user’s talker ID.

NOTE 6: How the IWF learns the LMR user’s talker ID is outside the scope of the present document. In some LMR conventional systems, the talker ID becomes available shortly after the start of the call; in other systems, it is not available until the end of the call.

10. The IWF sends an IWF talker ID update to the MCPTT server informing the server that a new talker is using the floor, but the floor should not be released.

11. The MCPTT server sends Floor taken messages to the affiliated users in the MCPTT system. The MCPTT ID in the floor taken messages is the new talker ID contained in the IWF talker ID update.

NOTE 7: All other floor participants (not shown) that are part of this group call receive a floor taken message, so that the other floor participants learn the identity of the newly granted talker.

12. If the group has other affiliated LMR users than the calling party, and the MCPTT server has received individual affiliations from those LMR users, an individual IWF floor taken message is sent to the IWF for each affiliated LMR user.

10.13.3.2 Group call with talker ID update initiated by an LMR user on an interworking group defined in the LMR system

In this procedure, an LMR user in a legacy conventional FM radio system initiates a group call on an interworking group defined in the LMR system. The talker ID is not known at the start of the call and is updated after media transmission begins. The signalling procedure is described in figure 10.13.3.2-1.

This subclause is based upon subclause for pre-arranged group call setup in 3GPP TS 23.379 [7], subclause 10.6.2.3.1.1.2.

Pre-conditions:

1. The interworking group information is known at the MCPTT server and the IWF by configuration or group creation. The interworking group has been defined in the LMR system.

2. MCPTT client 1 and MCPTT client 2 are registered and their respective users are authenticated and authorized to use the MCPTT service.

3. The users in this interworking group have been affiliated to the interworking group.

4. The mapping relationship of group and user identities between the MCPTT system and the LMR system has been configured at the IWF.

5. The LMR user in a legacy conventional FM radio system initiates a group call.

NOTE 1: For all the signalling messages passing through the IWF between the MCPTT system and the LMR system, the IWF performs the identity conversion and protocol translation.

Figure 10.13.3.2-1: Group call with talker ID update initiated by an LMR user on an interworking group defined in the LMR system

1. The IWF sends an IWF group call request(s) to the MCPTT server for call establishment. An individual IWF group call request is sent to the MCPTT server for each affiliated MCPTT user in the group, in this example scenario to the users in MCPTT clients 1 and 2. In this case floor control is also requested and an indication of implicit floor request is included. The IWF uses its pre-configured MCPTT ID in the group call request.

2. The MCPTT server sends a group call request(s) to the target MCPTT user(s) as described in 3GPP TS 23.379 [7]. The LMR user is in a legacy conventional FM radio system so E2EE is not specified, and transcoding is needed at the IWF.

3. MCPTT client(s) receiving the group call request, acknowledge towards the MCPTT server by sending a group call response.

4. The MCPTT server acknowledges the IWF group call request(s) by sending an IWF group call response(s) to the IWF.

NOTE 2: How the IWF group call response(s) is handled in the IWF / LMR system and how the other LMR users are being called is outside the scope of the present document.

5. The interworking group call has successfully established media plane for communication and any user can transmit media. The LMR system where the interworking group is defined is the controlling system of the group call and manages the floor control.

NOTE 3: How the floor control is managed in the LMR system is outside the scope of the present document.

6. Because the group call request contained an implicit floor request, and no other users are requesting the floor, the IWF sends an IWF floor taken message to the MCPTT server confirming that the IWF has the floor. An individual IWF floor taken message is sent to the MCPTT server for each affiliated MCPTT user in the group, in this example scenario to the users in MCPTT clients 1 and 2.

7. The MCPTT server sends Floor taken to the target MCPTT user(s) in the MCPTT system. The MCPTT ID in the floor taken messages is the pre-configured IWF MCPTT ID.

8. At some time after media transfer begins, the IWF receives knowledge of the LMR user’s talker ID.

NOTE 4: How the IWF learns the LMR user’s talker ID is outside the scope of the present document. In some LMR conventional systems, the talker ID becomes available shortly after the start of the call; in other systems, it is not available until the end of the call.

9. The IWF sends an IWF floor taken to the MCPTT server informing the server that a new talker is using the floor, but the floor should not be released. An individual IWF floor taken message is sent to the MCPTT server for each affiliated MCPTT user in the group, in this example scenario to the users in MCPTT clients 1 and 2

10. The MCPTT server sends Floor taken messages to the target MCPTT user(s) in the MCPTT system. The MCPTT ID in the floor taken messages is the new talker ID contained in the IWF talker ID update.

NOTE 5: All other floor participants (not shown) that are part of this group call receive a floor taken message, so that the other floor participants learn the identity of the newly granted talker.