15 Tunnelling

23.2053GPPBearer-independent circuit-switched core networkRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

NOTE: All message sequence charts in this clause are examples. All valid call establishment message sequences can be derived from the example message sequences and associated message pre-conditions.

15.1 Forward Bearer Establishment

The following clauses describe the requirements for tunnelling transport mechanism within the bearer independent CS core network. These requirements are supplementary to those already stated in the Call Establishment clause. If out^‑of‑band transcoder control is applied for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3].

15.1.1 Outgoing Side

15.1.1.1 Tunnel Selection

If the MGW selection occurs before the IAM is sent, the (G)MSC server uses the Prepare Bearer procedure to indicate a tunnel support to the MGW. Depending upon the received value, the MGW shall determine whether tunnelling shall actually be used and when to send the tunnel data (bullet 1 in figure 15.2).

If the (G)MSC server indicated that tunnelling is not supported, the bearer will be established as described in clause Call Establishment.

If the (G)MSC server indicated that fast tunnelling is supported, the MGW may select which tunnelling method to use. In this case the MGW shall select either fast tunnelling or the non-tunnelling method.

If the (G)MSC server indicated that delayed tunnelling is supported, the MGW may select which tunnelling method to use. In this case the MGW shall select either delayed tunnelling or the non-tunnelling method.

If the MGW is allowed to choose whether tunnelling is to be used, it shall select either fast, delayed, or the non‑tunnelling method.

The MGW shall respond to the Prepare Bearer procedure with the used tunnel indication, when the type of tunnelling mechanism has been decided.

NOTE: For a given bearer type, other specifications may describe the mechanism to be used to transport bearer control information. An MGW is only required to comply with that specification.

15.1.1.2 Initial addressing

If the MGW selection has occurred, the MGW shall respond to the Prepare Bearer procedure indicating whether tunnelling is allowed and what type of tunnelling is used – fast or delayed forward. The (G)MSC server provides a tunnel indicator to the succeeding node in the IAM to indicate that tunnelling is to be used. For fast tunnelling, the (G)MSC server waits for the MGW to use the Tunnel Information Up procedure to provide the tunnel data before the IAM is sent.

If the MGW indicates that tunnelling is not to be used, then tunnel indicator is not included in the Initial Address message and the bearer will be established as described in clause Call Establishment.

If the MGW has not been selected yet, then the (G)MSC server decides whether delayed tunnelling is supported or not. If the delayed tunnelling is supported the tunnel indicator is included to the Initial Address message to indicate that. Otherwise the tunnel indicator is not included to the Initial Address message and the bearer will be established as described in clause Call Establishment.

15.1.1.3 Fast forward tunnelling

The tunnel data is transferred in the IAM and the subsequent Tunnel Information message(s).

Before the IAM is sent, the (G)MSC server waits for the MGW to use the Tunnel Information Up procedure to supply the tunnel data. The (G)MSC server sends the received tunnel data to the succeeding node in the IAM (bullet 2 in example, clause 15.2).

When the (G)MSC server receives a Tunnel Information message from the succeeding node the (G)MSC server uses the Tunnel Information Down procedure to supply the MGW with the received tunnel data (bullet 5 in example sequence 15.2).

15.1.1.4 Delayed forward tunnelling

The tunnel data is transferred in the Tunnel Information messages following the Bearer Information message.

If tunnel indicator was included in the IAM indicating that delayed tunnelling is supported, the succeeding node may include the tunnel indicator to the Bearer Information message. If the tunnel indicator is received the (G)MSC server indicates the delayed tunnel support in the Establish Bearer procedure.

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the Tunnel Information message to the succeeding node.

When the (G)MSC server receives a Tunnel Information message from the succeeding node, the (G)MSC server uses the Tunnel Information Down procedure to send the received tunnel data to the MGW.

15.1.1.5 Bearer control signalling transfer

The tunnelling of the bearer control signalling is transported transparently through the (G)MSC server during the call establishment and at any other time until Release is sent or received.

15.1.2 Incoming Side

15.1.2.1 Initial addressing

The (G)MSC server receives the possible tunnel indicator and the tunnel data in IAM. Based on received information it provides the tunnel support indication and the tunnel data to the MGW.

15.1.2.2 Tunnel Selection

If the tunnel indicator was received in the IAM, the (G)MSC server uses the received tunnel indicator to indicate the support of tunnel to the MGW. If the tunnel indicator is received in the IAM without tunnel data, the (G)MSC server checks the value of the tunnel indicator. If the tunnel indicator indicates that tunnel mechanism is to be used then delayed tunnelling is indicated to the MGW. If the tunnel indicator indicates that tunnel mechanism is supported the (G)MSC server decides whether the delayed tunnel is supported or non tunnelling mechanism is used. If both tunnel indicator and tunnel data are received in the IAM, fast tunnelling is indicated to the MGW.

If no tunnel indicator was received in the IAM, then the preceding node has indicated that non-tunnelling mechanism is to be used.

The (G)MSC server uses the Prepare Bearer procedure to supply the tunnel support indication to the MGW.

The MGW decides based on the received tunnel support indication from the (G)MSC server whether to use delayed tunnelling or not. In the response the MGW provides the used tunnel indication to the (G)MSC server.

15.1.2.3 Fast forward tunnelling

The tunnel data is transferred in the IAM and the subsequent Tunnel Information message(s).

The (G)MSC server sends the tunnel data received in the IAM to the MGW using the Tunnel Information Down procedure (bullet 3 in example, clause 15.2).

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the Tunnel Information message to the preceding node (bullet 4 in example, clause 15.2).

15.1.2.4 Delayed forward tunnelling

The tunnel data is transferred in the Tunnel Information messages following the Bearer Information message.

If tunnel indicator was received in the IAM indicating that delayed tunnel is supported and delayed tunnelling was indicated by the MGW, the (G)MSC server shall include the tunnel indicator to the Bearer Information message which is sent to the preceding node.

When the (G)MSC server receives a Tunnel Information message from the preceding node, the (G)MSC server uses the Tunnel Information Down procedure to send the received tunnel data to the MGW.

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the Tunnel Information message to the preceding node.

15.1.2.5 Bearer control signalling transfer

The tunnelling of bearer control signalling is transported transparently during the call establishment and at any other time until Release is sent or received.

15.1.2.6 Example

Figure 15.1 shows the network model for the forward tunnelling transport mechanism. The "squared" line represents the call control signalling. The "dotted" line represents the bearer control signalling. The (G)MSCa seizes one context with two bearer terminations in MGWa. The bearer termination T1 is used for the bearer towards the incoming side of (G)MSCa and the bearer termination T2 is used for the tunnelling towards the succeeding MGW. The (G)MSCb seizes one context with two bearer terminations in MGWb. The bearer termination T3 is used for the bearer towards the outgoing side of (G)MSCb and the bearer termination T4 is used for the tunnelling towards the preceding MGW.

Figure 15.1: Forward Tunnelling Transport Mechanism (network model)

Figure 15.2 shows the message sequence example for fast forward tunnelling transport mechanism. In the example (G)MSCa indicates to MGWa that fast tunnelling is requested. After MGWa has notified the (G)MSCa of the tunnel data, the IAM is sent to the (G)MSCb. The (G)MSCb indicates to MGWb that fast tunnelling is supported and sends the received tunnel data to MGWb. Once MGWb has sent the tunnel data to the (G)MSCb, the (G)MSCb sends a Tunnel Information message with the tunnel data to the (G)MSCa. The (G)MSCa sends the received tunnel data to MGWa. The handling of Continuity message, through-connection and answer is as normal for non-tunnelled forward bearer establishment.

Figure 15.2: Fast Forward Tunnelling Transport Mechanism (message sequence chart)

15.2 Backward Bearer Establishment

The following clauses describe the additional requirements for tunnelling transport mechanism within the bearer independent CS core network. If out-of-band transcoder control is applied for a speech call, it shall be performed in accordance with 3GPP TS 23.153[3].

15.2.1 Outgoing Side

15.2.1.1 Tunnel Selection

The (G)MSC server uses the Prepare Bearer procedure to indicate a tunnel support to the MGW. Depending upon the received value, the MGW shall determine whether tunnelling shall actually be used and when to send the tunnel data (bullet 1 in example, clause 15.4).

If the (G)MSC server indicated that tunnelling will be not supported, the bearer is established as described in clause Call Establishment.

If the (G)MSC server indicated that fast tunnelling is supported, the MGW may select which tunnelling method it can use. In this case the (G)MSC may select either fast tunnelling or the non-tunnelling method.

If the (G)MSC server indicated that delayed tunnelling is supported, the MGW may select which tunnelling method it can use. In this case the (G)MSC server may select either delayed tunnelling the non-tunnelling method.

If the MGW is allowed to choose whether tunnelling is to be used, it shall select either fast, delayed or the non‑tunnelling method.

After MGW has decided which tunnelling mechanism to use , it responds to the Prepare Bearer procedure with the used tunnel indication.

15.2.1.2 Initial addressing

The MGW shall respond to the Prepare Bearer procedure to indicate whether tunnelling is allowed and what type of tunnelling is used – fast or delayed forward. The (G)MSC server provides a tunnel indicator to the succeeding node in the IAM. For fast tunnelling, the (G)MSC server waits for the MGW to use the Tunnel Information Up procedure to provide the tunnel data before the IAM is sent.

If the MGW indicates that tunnelling is not to be used, the bearer will be established as described in clause Call Establishment.

15.2.1.3 Fast forward tunnelling

The tunnel data is transferred in the IAM and the subsequent Tunnel Information message(s).

When the (G)MSC server receives a Tunnel Information message from the succeeding node the (G)MSC server uses the Tunnel Information Down procedure to supply the MGW with the received tunnel data.

15.2.1.4 Delayed backward tunnelling

The tunnel data is transferred in the Tunnel Information messages following the IAM.

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the Tunnel Information message to the succeeding node (bullet 5 in example, clause 15.4).

15.2.1.5 Bearer control signalling transfer

The tunnelling of bearer control signalling is transported transparently through the (G)MSC server during the call establishment and at any other time until Release is sent or received.

15.2.2 Incoming Side

15.2.2.1 Initial addressing

The (G)MSC server receives the possible tunnel indicator and the tunnel data in the IAM. Based on received information it provides the tunnel support indication and the tunnel data to the MGW.

15.2.2.2 Tunnel Selection

If the tunnel indicator was received in the IAM, the (G)MSC server uses the received tunnel indicator to indicate the support of tunnel to the MGW. If the tunnel indicator is received in the IAM without tunnel data, delayed tunnelling is indicated to the MGW. If tunnel indicator and tunnel data are received in the IAM, fast tunnelling is indicated to the MGW.

The (G)MSC server uses the Establish Bearer procedure to supply the tunnel support indication to the MGW (bullet 2 in example, clause 15.4).

15.2.2.3 Fast forward tunnelling

The tunnel data is transferred in the IAM and the subsequent Tunnel Information message(s).

The (G)MSC server sends the tunnel data received in the IAM to the MGW using the Tunnel Information Down procedure.

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the Tunnel Information message to the preceding node.

15.2.2.4 Delayed backward tunnelling

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the Tunnel Information message to the preceding node (bullet 3 in example, clause 15.4).

When the MGW receives an Nb User Plane Initialisation message (bullet 5a in example sequence 15.4). before the subsequent Tunnel Information Down procedure (bullet 6 in example sequence 15.4) , t he MGW may acknowledge this Nb User Plane Initialisation message without waiting for the Tunnel Information Down procedure, and send the acknowledge message towards the IP address and port that were supplied as source within the IP packet transporting the Nb User Plane Initialisation message (bullet 5b in example sequence 15.4). The MGW shall use the same RTP Payload-Type number for the acknowledge message, which was used in the RTP header of the packet transporting the Nb User Plane Initialisation message.

Alternatively, when the MGW receives an Nb User Plane Initialisation message (bullet 5a in example sequence 15.4). before the subsequent Tunnel Information Down procedure (bullet 6 in example sequence 15.4), the MGW may wait for the Tunnel Information Down procedure, before sending the Nb User Plane Initialisation acknowledge message (bullet 6a in example sequence 15.4). While waiting for the Tunnel Information Down procedure, the MGW may receive repetition(s) of the Nb User Plane Initialisation message and shall not treat this as error case.

When the (G)MSC server receives a Tunnel Information message from the preceding node, the (G)MSC server uses the Tunnel Information Down procedure to send the received tunnel data to the MGW (bullet 6 in example, clause 15.4).

After receiving the Tunnel Information Down procedure (bullet 6 in example sequence 15.4) and acknowledging the NbFP Init message (bullet 5b or 6a in example sequence 15.4), the MGW shall notify the MSC server about the bearer establishment (bullet 7 in example sequence 15.4).

15.2.2.5 Bearer control signalling transfer

The tunnelling of bearer control signalling is transported transparently through the (G)MSC server during the call establishment and at any other time until Release is sent or received.

15.2.2.6 Example

Figure 15.3 shows the network model for the backward delayed tunnelling transport mechanism. The "squared" line represents the call control signalling. The "dotted" line represents the bearer control signalling. The (G)MSCa seizes one context with two bearer terminations in MGWa. The bearer termination T1 is used for the bearer towards the incoming side of (G)MSCa and the bearer termination T2 is used for the tunnelling towards the succeeding MGW. The (G)MSCb seizes one context with two bearer terminations in MGWb. The bearer termination T3 is used for the bearer towards the outgoing side of (G)MSCb and the bearer termination T4 is used for the tunnelling towards the preceding MGW.

Figure 15.3: Delayed Backward Tunnelling Transport Mechanism (network model)

Figure 15.4 shows the message sequence example for backward tunnelling transport mechanism. In the example the (G)MSCa indicates to MGWa that delayed tunnelling is requested. After MGWa has responded the (G)MSCa of tunnelling, the IAM is sent to (G)MSCb. The (G)MSCb indicates to MGWb that delayed tunnelling is supported. Once MGWb has sent the tunnel data to the (G)MSCb, the (G)MSCb sends the received tunnel data in the Tunnel Information message to the (G)MSCa. The (G)MSCa sends the received tunnel data to MGWa. Once MGWa has sent the tunnel data to the (G)MSCa, the (G)MSCa sends the received tunnel data in the Tunnel Information message to the (G)MSCb. The (G)MSCb sends the received tunnel data to MGWb. The handling of Continuity message, through-connection and answer is as normal for non-tunnelled backward bearer establishment.

Figure 15.4: Delayed Backward Tunnelling Transport Mechanism (message sequence chart)