5 General architecture

3GPP43.069Release 17Stage 2TSVoice Broadcast Service (VBS)

5.1 Group Call Register (GCR)

The general architecture of GSM is maintained. In addition, a network function is required which is used for registration of the broadcast call attributes, the Group Call Register (GCR).

The GCR function is mainly a database function, holding information about voice broadcast calls.

NOTE 1: The GCR implementation is not specified. It may be realized e.g. as a new network node, in a PABX directly attached to an MSC, inside an MSC or as an HLR. The interface between the GCR function and other functions is not specified in the GSM technical specifications. As a consequence, the functional split between MSC and GCR as developed in the present document is only indicative, and other functional splits can be implemented.

The GCR data for a specific voice broadcast call is set at the creation of the broadcast call attributes, and can be subsequently modified. No support for these functions is specified in the GSM technical specifications.

In a RANflex configuration with group call redundancy GCRs associated to MSCs belonging to the same redundancy pool need to communicate with each other by means of SYNC_GCR messages.

Figure 1: Functional architecture with a Group Call Register

NOTE: Figure 1a shows the configuration with only one RANflex MSC pool. Other configurations with more than one RANflex MSC pool are possible.

Figure 1a: Functional architecture with a Group Call Register in a RANflex configuration

NOTE: Figure 1b shows the configuration with only one RANflex MSC pool. Other configurations with more than one RANflex MSC pool are possible.

Figure 1b: Functional architecture with a Group Call Register in a RANflex configuration with group call redundancy

Dashed lines in figure 1, figure 1a and figure 1b indicate MAP interfaces, thin solid lines indicate ISUP interfaces, bold solid lines indicate interfaces without standardized protocol.

Lines in figure 1b ending at an MSC Redundancy Pool actually connect to the selected MSC within the redundancy pool. For MSC selection see subclause 5.3.1.

The signalling between the entities shown in figure 1, figure 1a and figure 1b, for the two cases of service subscriber and dispatcher originated calls, shall be as defined in the following.

Service subscriber originated: The service Subscriber’s VMSC shall perform subscription checking against VLR records. In a RANflex configuration it shall then derive from the service subscriber’s current location area the address of the group call serving MSC which may be different from the VMSC. In a RANflex configuration with group call redundancy this address identifies a group call serving MSC redundancy pool.

If one of the following configurations applies:

a) no RANflex configuration;

b) in a RANflex configuration , if the VMSC is the group call serving MSC; or

c) in a RANflex configuration with group call redundancy, if the VMSC belongs to the group call serving MSC redundancy pool,

the VMSC shall consult its GCR to determine the broadcast call attributes related to its MSC area and whether it is the group call anchor MSC for that voice broadcast call. If it is not, the GCR shall provide with the broadcast call reference and the routing information identifying the group call anchor MSC (the group call anchor MSC redundancy pool in a RANflex configuration with group call redundancy) to the originating VMSC. The originating MSC shall then route the voice broadcast call to the anchor MSC.

If one of the following configurations applies:

d) in a RANflex configuration, if the VMSC is not the group call serving MSC; or

e) in a RANflex configuration with group call redundancy, if the VMSC does not belong to the group call serving MSC redundancy pool,

the VMSC shall consult the group call serving MSC by means of the MAP service SEND_GROUP_CALL_INFO and retrieve the group call anchor MSC address. The originating VMSC shall then route the voice broadcast call to the anchor MSC or the anchor MSC pool.

If the initiation of the voice broadcast call had specified originator-to-dispatcher information and processing of originator‑to‑dispatcher information is supported by the originating VMSC, the originator-to-dispatcher information is transformed by the originating VMSC into UUS1 and sent to the anchor MSC or the anchor MSC pool. If the originating VMSC is the group call anchor MSC (or belongs to the group call anchor MSC redundancy pool), along with the broadcast call attributes, the GCR shall provide information on all group call relay MSCs or group call relay MSC pools to be involved.

The group call anchor MSC shall set up links to all group call relay MSCs or relay MSC pools. It shall also initiate setup of point-to-point connections to the dispatchers associated to the voice broadcast call (see subclause 8.1.2.2); if UUS1 information has been received in the signalling for call setup from the originating VMSC, this UUS1 information is included in the setup of point-to-point connections to the dispatchers. Each MSC involved in a voice broadcast call obtains its own broadcast call attributes from the GCR related to the MSC.

Dispatcher originated: In the case of dispatchers calling from an external network, the call request, in the form of an ISDN number, shall be received at a GMSC. The number shall be analysed and the call shall be directly routed to the group call anchor MSC or anchor MSC pool by the GMSC based on the called identity without requesting an HLR. The group call anchor MSC shall interrogate the GCR and obtain the broadcast call attributes. If an identical voice broadcast call is currently in progress, the dispatcher shall be connected to this call and no new call shall be initiated. When interrogating the GCR, the identity of the calling dispatcher is compared with the list of dispatchers which are allowed to initiate the call. If the dispatcher is not in the list, or an identity is not provided, the network shall reject the call.

NOTE 2: A dispatcher may be a user of the GSM network in which the VBS service is provided or may be connected to a PABX which is connected to the MSC containing the GCR. A dispatcher which is registered in the GCR for a certain voice broadcast call and which also has a subscription for VBS with the same group ID as the voice broadcast call for which he is dispatcher shall deactivate this group ID when he is located in the corresponding group call area in order to avoid conflicts between paging for the dispatcher and notifications for the group ID.

5.2 Voice broadcast call responsibility

The MSC responsible for the voice broadcast call is the one nominated within the GCR or the one to which the call is routed from the GMSC in the case of a dispatcher originated call. This MSC is termed the group call anchor MSC.

If the group call area extends beyond one MSC area then any MSCs controlling cells in the area outside of the group call anchor MSC are referred to as group call relay MSCs.

In a RANflex configuration a given location area within the pool area is served (with group call services) by a single predefined group call serving MSC which for a specific group call is either anchor or relay MSC.

In a RANflex configuration with group call redundancy a given location area within the pool area is served (with broadcast call services) by predefined group call serving MSCs which form up the location area’s group call serving MSC redundancy pool. One MSC shall not belong to more than one group call MSC redundancy pool. For a specific ongoing broadcast call the group call serving redundancy pool is either an anchor or a relay redundancy pool.

5.3 RANflex configuration with group call redundancy

5.3.1 MSC selection in a RANflex configuration with group call redundancy

In a RANflex configuration with group call redundancy, messages routed towards a group call MSC redundancy pool eventually need to be processed by a selected MSC out of the redundancy pool. MSC selection is done with appropriate routing mechanisms at call setup time.

Mixed configurations where e.g. the anchor MSC belongs to an anchor MSC redundancy pool but the relay MSC does not belong to a Relay MSC redundancy pool may be considered a RANflex configuration with group call redundancy where e.g. the relay MSC redundancy pool is formed up by just one relay MSC.

In a RANflex configuration with group call redundancy the following messages sent to an MSC do not address an individual MSC but an MSC redundancy pool:

– IAM (from dispatcher to Anchor MSC);

– IAM (from VMSC to Anchor MSC);

– SEND_GROUP_CALL_INFO (from VMSC to Group Call Serving MSC); and

– PREPARE_GROUP_CALL (from Anchor MSC to Relay MSC).

Network routing ensures that these messages are routed to one of the available (i.e. not out of service) MSCs within the redundancy pool. MSC selection by network routing can be based e.g. on a predefined prioritization mechanism or a load distribution mechanism but the exact mechanism is out of scope of this specification.

Once the message is received by one of the available MSCs, the receiving MSC shall check whether there is the need to forward the message to another specific MSC within the redundancy pool (for detailed behaviour of the MSC see subclauses 11.4, 11.5, and 11.5A). Network routing ensures that the forwarded message is routed to the specific MSC. Specific MSC routing may be done e.g. with address prefixes and is out of scope of this specification.

If the message forwarding MSC detects that the specific target MSC is out of service, it shall handle the request locally and repeat the GCR interrogation with an override indication.

In a RANflex configuration with group call redundancy the following messages sent to an MSC address an individual MSC and not an MSC redundancy pool:

– IAM (dispatcher originated) when forwarded within the group call anchor MSC redundancy pool from selected Anchor MSC to the Anchor MSC where the broadcast call is on-going;

– IAM (VMSC originated) when forwarded within the group call anchor MSC redundancy pool from selected Anchor MSC to the Anchor MSC where the broadcast call is on-going;

– IAM (from Anchor MSC to Relay MSC) routed with the temporary group call number allocated by the Relay MSC;

– SEND_GROUP_CALL_INFO (VMSC originated) when forwarded within the group call serving MSC redundancy pool from selected group call serving MSC to the group call serving MSC where the broadcast call is on-going; and

– Subsequent messages within a dialogue opened by a PREPARE_GROUP_CALL message (PREPARE_GROUP_CALL_ACK, SEND_GROUP_CALL_END_SIGNAL, FORWARD_GROUP_CALL_SIGNALLING; PROCESS_GROUP_CALL_SIGNALLING). MAP dialogue handling ensures that messages are exchanged between origin and selected destination of the dialogue.

Network routing ensures that these messages are routed to the individual MSC within the redundancy pool.

5.3.2 GCR synchronization in a RANflex configuration with group call redundancy

GCRs associated to MSCs which belong to the same redundancy pool need to synchronize their transient data. This is done by means of SYNC_GCR messages. As soon as transient data are modified in a GCR as a result of GCR interrogation from the associated MSC, the modification is propagated to the other GCRs.

This mechanism prevents the establishment of two simultaneous group calls with the same group call reference controlled by two different anchor MSCs.

5.3.3 GCR Restoration in a RANflex configuration with group call redundancy

When a GCR (and its associated MSC) restarts after planned or unplanned outage, its transient data may be lost or may be out of sync due to lost SYNC_GCR messages. To restore the transient data, the GCR shall after restart

– stop all T3 timers;

– delete all stored initial talker information; and

– mark all GCR records with "transient data not reliable".

When transient data are read while processing a GCR interrogation, the GCR shall check whether the record is marked "transient data not reliable". If so, the GCR shall retrieve transient data from the other GCR(s) within the redundancy pool by means of a SYNC_GCR message with request indication, store it and reset the mark "transient data not reliable" before processing the GCR interrogation. If the retrieval of transient data is unsuccessful, the GCR shall assume that the call is not on-going, reset the mark "transient data not reliable" and process the GCR interrogation.

When processing a received SYNC_GCR message without request indication while the record is marked "transient data not reliable", the GCR shall accept the request and reset the "transient data not reliable" mark.

When processing a received SYNC_GCR message with request indication while the record is marked "transient data not reliable", the GCR shall return a negative response (failure) and keep the "transient data not reliable" mark.