B.2 Handover/Relocation related generic transparent Containers over RANAP, S1-AP and GTP

29.2743GPP3GPP Evolved Packet System (EPS)Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)Release 18Stage 3TS

Handover/Relocation related generic transparent containers are defined in 3GPP TS 25.413 [33] and 3GPP TS 36.413 [10] ("Source to Target Transparent Container" IE and "Target to Source Transparent Container" IE) to carry UTRAN, E-UTRAN or GERAN specific information via CN interfaces in a RAT-agnostic way.

The encoding of these handover/relocation related generic transparent containers is different in RANAP and S1-AP. See 3GPP TS 36.413 [10] Annex C. The difference is that the "Source to Target Transparent Container" IE and "Target to Source Transparent Container" IE are ASN.1 encoded over RANAP as "IE-ID||criticality||OT-LI||octets" (i.e. one length field only for the open type field) and over S1AP as "IE-ID||criticality||OT-LI||OCT-LI||octets" (i.e. with 2 length fields, one for the open type field ("OT-LI"), one for the octet string encoding ("OCT-LI")), while "octets" contain the actual RAT specific handover/relocation information.

This gives the following chain of encodings (represented in the notation introduced in the Notes above) end-to-end.

LTE to LTE

Figure B.2-1: LTE to LTE – Encoding of Generic Transparent Containers

In the case of LTE-LTE handover, the "octets" contain the "Source eNB to Target eNB Transparent Container" (defined as an ASN.1 SEQUENCE in 3GPP TS 36.413[10]).

The source MME, after decoding the HO REQUIRED message of S1AP, passes transparently the "sequence" to the target MME.

The target MME encodes similarly at target side with the same definitions: it feeds the received "sequence" into the S1AP ASN.1 encoder in order to encode the HO REQUEST message towards the target eNB. The "sequence" is then extracted from the S1AP ASN.1 of eNB and given to application part of eNB.

LTE to 3G

Figure B.2-2: LTE to 3G – Encoding of Generic Transparent Containers

At source side, the same encoding is done but for LTE to 3G handover, this time the "octets" on the line is the "Source RNC to Target RNC Transparent Container" (encoded according to the target system RANAP i.e. as an ASN.1 SEQUENCE in 3GPP TS 25.413 [33]).

Again the source MME passes transparently the "sequence" to the target MME i.e. the "Source RNC to Target RNC Transparent Container".

At the target side, the RANAP RELOCATION REQUEST message was not upgraded: the "sequence" received from the Gn or S3 interface ("Source RNC to Target RNC Transparent Container") is not encoded as an OCTET STRING as on S1, but directly represent the "Source To Target Transparent Container" within the RANAP:RELOCATION REQUEST message, which in case of inter-RAT handover to 3G represent the "Source RNC to Target RNC Transparent Container", transported on the Iu interface as the "IE" part of the "IE container". There is no additional length field added as on the S1 interface ("OCT-LI").

The target side remains therefore fully backwards compatible with UMTS release 7.

3G to LTE

Figure B.2-3: 3G to LTE – Encoding of Generic Transparent Containers

The RELOCATION REQUIRED message was upgraded from release 8 onwards renaming the previously contained "Source RNC to Target RNC Transparent Container" to "Source to Target Transparent Container", being able to transport also a "Source eNB to Target eNB Transparent Container".

Despite being defined as an octet string, in order to not impact the R7 SGSN, the octet string was specified as "to be replaced" by either the UTRAN or E-UTRAN specific container. This fact is explained e.g. within the NOTE in the ASN.1 of 3GPP TS 25.413 [33] ], as shown in this excerpt:

Source-ToTarget-TransparentContainer ::= OCTET STRING

— This IE is a transparent container, the IE shall be encoded not as an OCTET STRING but according to the type specifications of the target system.

— Note: In the current version of this specification, this IE may either carry the Source RNC to

— Target RNC Transparent Container or the Source eNB to Target eNB Transparent Container IE as

— defined in [49]

By so doing, the Release 7 source SGSN receives only one length field (the "OT-LI") instead of two (the "OT-LI and the "OCT-LI") as if it would receive an "Source RNC to Target RNC Transparent Container" from a Release 7 RNC, ensuring fully Release 7 backwards compatibility as requested by 3GPP TS 23.401 [3] Annex D. This is illustrated in Figure B.1-3 above.

As explained above, this Release 7 backwards compatibility constraint only applies to RANAP to cope with Release 7 SGSN nodes and does NOT apply to LTE. This is why the note is NOT present in the ASN.1 of 3GPP TS 36.413 [10] for LTE i.e. the S1AP octet string does not need "to be replaced".

Then "sequence" is passed transparently to the target MME. The target MME encodes the "sequence" within an OCTET STRING resulting in two length fields as expected by target eNB ASN.1 S1AP decoder.