Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.283  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   10…   10.2…   10.3…   10.3.2   10.3.3…   10.3.4…   10.3.5…   10.3.6…   10.3.7…   10.3.8…   10.4…   10.5…   10.6…   10.6.2…   10.6.3…   10.7…   10.8…   10.11…   10.12…   10.14…   10.15…   10.17… 
10.12 LMR security transport  10.12.1 Information flows for LMR security transport  10.12.2 LMR key management messages  10.12.2.1 General  10.12.2.2 MC service client initiated  10.12.2.3 IWF initiated  10.13 Analogue FM/TIA-603-D and other legacy LMR interworking  10.13.1 General  10.13.2 Interworking Concepts  10.13.3 Procedures  10.13.3.1 Group call with talker ID update initiated by an LMR user on an interworking group defined in the MCPTT system  10.13.3.2 Group call with talker ID update initiated by an LMR user on an interworking group defined in the LMR system 
...

 

10.12  LMR security transport  p. 163

10.12.1  Information flows for LMR security transport  p. 163

10.12.1.1  Non-3GPP security message request  p. 163

Table 10.12.1.1-1 describes the information flow non-3GPP security message request from the MC service server to the IWF, from the IWF to the MC service server, from the MC service server to the MC service client and from the MC service client to the MC service server.
Information element Status Description
MC service IDMThe identity of the MC service user
URI of LMR security functional entityMURI of LMR key management functional entity user profile parameter defined in TS 23.379
LMR typeOThe LMR technology, e.g. TETRA, P25. Required when sent toward the MC service client.
PayloadMOpaque payload. Contents and format are out of 3GPP scope.
Up

10.12.1.2  Non-3GPP security message response  p. 163

Table 10.12.1.2-1 describes the information flow non-3GPP security message response from the MC service server to the IWF, from the IWF to the MC service server, from the MC service server to the MC service client and from the MC service client to the MC service server.
Information element Status Description
MC service IDMThe identity of the MC service user
URI of LMR security functional entityMURI of LMR key management functional entity user profile parameter defined in TS 23.379
Up

10.12.2  LMR key management messages  p. 164

10.12.2.1  General  p. 164

This subclause defines end to end messaging to convey the non-3GPP, LMR security information opaquely (message contents are out of 3GPP's scope) across the MC system, between the IWF and the LMR aware MC service client. The end to end messasges are service independent, any MC service may support them.

10.12.2.2  MC service client initiated  p. 164

Figure 10.12.2.2-1 describes the case where an MC service client sends LMR security information to the IWF.
Pre-conditions:
  1. The MC service client is registered and the user is authenticated and authorized to use the MC service server.
Reproduction of 3GPP TS 23.283, Fig. 10.12.2.2-1: Non-3GPP security messaging, MC service client to the IWF
Figure 10.12.2.2-1: Non-3GPP security messaging, MC service client to the IWF
Up
Step 1.
The MC service client sends s a non-3GPP security message request to the MC service server. The contents of the message are opaque to the MC service and are out of scope of 3GPP.
Step 2.
The MC service server forwards the contents of the non-3GPP security message request to the IWF.
Step 3.
The IWF acknowledges with a non-3GPP security message response to the MC service server.
Step 4.
The MC service server acknowledges with a non-3GPP security message response to the MC service client.

10.12.2.3  IWF initiated  p. 164

Figure 10.12.2.3-1 describes the case where the IWF sends LMR security information to an MC service client.
Pre-conditions:
  1. The MC service client is registered and the user is authenticated and authorized to use the MC service server.
Reproduction of 3GPP TS 23.283, Fig. 10.12.2.3-1: Non-3GPP security, from the IWF to MC service client
Figure 10.12.2.3-1: Non-3GPP security, from the IWF to MC service client
Up
Step 1.
The IWF sends a non-3GPP security message request to the MC service server. The contents of the message are opaque to the MC service and are out of scope of 3GPP.
Step 2.
The MC service server forwards the contents of non-3GPP security message request to the MC service client.
Step 3.
The MC service client acknowledges with a non-3GPP security message response to the MC service server.
Step 4.
The MC service server forwards the non-3GPP security message response to the IWF.

10.13  Analogue FM/TIA-603-D and other legacy LMR interworking |R16|  p. 165

10.13.1  General  p. 165

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.
Up

10.13.2  Interworking Concepts  p. 165

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.
  • 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.
Up

10.13.3  Procedures  p. 166

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  p. 167

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 subclause 10.6.2.3.1.1.2 of TS 23.379.
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.
Reproduction of 3GPP TS 23.283, Fig. 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
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
Up
Step 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.
Step 2.
The MCPTT server calls the affiliated users from the MCPTT system as described in TS 23.379. The LMR user is in a legacy conventional FM radio system so E2EE is not specified, and transcoding is needed at the IWF.
Step 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.
Step 4.
The IWF returns IWF group call response(s) to the MCPTT server.
Step 5.
The MCPTT server confirms the successful establishment of the group call by sending an IWF Group call response to the IWF.
Step 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.
Step 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.
Step 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.
Step 9.
At some time after media transfer begins, the IWF receives knowledge of the LMR user's talker ID.
Step 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.
Step 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.
Step 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.
Up

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

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 subclause 10.6.2.3.1.1.2 of TS 23.379.
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.
Reproduction of 3GPP TS 23.283, Fig. 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
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
Up
Step 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.
Step 2.
The MCPTT server sends a group call request(s) to the target MCPTT user(s) as described in TS 23.379. The LMR user is in a legacy conventional FM radio system so E2EE is not specified, and transcoding is needed at the IWF.
Step 3.
MCPTT client(s) receiving the group call request, acknowledge towards the MCPTT server by sending a group call response.
Step 4.
The MCPTT server acknowledges the IWF group call request(s) by sending an IWF group call response(s) to the IWF.
Step 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.
Step 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.
Step 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.
Step 8.
At some time after media transfer begins, the IWF receives knowledge of the LMR user's talker ID.
Step 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
Step 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.
Up

Up   Top   ToC