A.2 Proxy-based interworking
23.4023GPPArchitecture enhancements for non-3GPP accessesRelease 18TS
In this scenario an Interworking Proxy (IWP) sits between the GTP-based PLMN and the PMIP-based PLMN to perform protocol conversion between the GTP protocol on one side and the PMIP and Diameter protocols on the other side.
Figure A.2-1: Roaming Via Interworking Proxy: a) GTP-based HPLMN to PMIP-based VPLMN; b) PMIP-based HPLMN to GTP-based VPLMN
The IWP is inserted transparently in the signalling and bearer path i.e. no changes to the GTP, PMIP and Diameter protocols are required.
Annex B (informative):
Guidance for Contributors to this Specification
The following guidance is provided for drafting figures for this specification that share some common procedures with TS 23.401 [4].
Representation of PMIP or GTP variants of S5/S8:
– Flows to TS 23.401 [4] will contain the complete procedures for GTP-based S5/S8.
– In TS 23.401 [4], clause(s) of a flow that is different for PMIP version of S5/S8 interface are shown surrounded by shaded box indexed by capital letter in ascending order, e.g. "A", "B", "C", etc.
At the bottom of the flow, the following text should be included, e.g.
NOTE 1: Procedure steps (A) and (B) for an PMIP-based S5/S8 are defined in this specification.
– In this specification, each step for the relevant clause, belonging to say annex A, of the flow should be indicated by "A.1, A.2, …". In this specification common clauses of the flow captured in TS 23.401 [4], should be indicated by shaded boxes with text, e.g. "Procedures in TS 23.401 [4], Figure x.y.z-k, before A", "Procedures in TS 23.401 [4], Figure x.y.z-k, between A and B", etc.
For an illustrative example of the drafting guidelines rule, please refer to Figure 5.4.1-1 in TS 23.401 [4] and corresponding Figure 5.4.1-1-1 in this specification.
Representation of different architectural cases:
– For each case supported, indicate the presence of the optional network entities that may be included in the procedure step. These optional entities appear between the source and destination of the procedure interaction arc as a gray circle. For example, a vPCRF may stand between the Serving GW and the hPCRF.
– In text following a procedure diagram, list the different cases supported by the figure.
– For each case that is supported, indicated what the role of the optional network entity is, when it occurs in the interaction. For example, "In the roaming case, the vPCRF forwards messages between the Serving GW and the PDN GW".
While it is possible to describe these interactions in each step in which they might occur, this will tend to clutter and complicate the procedure diagrams and should be avoided. A single paragraph found beneath each procedure including optional network elements should suffice to clarify that procedure.
Representation of the impact of multiple PDN connectivity:
– In text following a procedure diagram, list the specific impacts arising from multiple PDN connectivity. This will chiefly include a description of which interactions in the figure may be repeated N times for each PDN connected to.
The following guidance is provided for drafting figures related to the S2b interface in this specification:
Representation of PMIP or GTP variants of S2b in this specification:
– PMIP-based S2b call flows will contain the complete procedures;
– Clause(s) of a PMIP-based S2b flow that is different for the GTP variant of the S2b interface are shown surrounded by shaded box indexed by capital letter in ascending order, e.g. "A", "B", "C", etc.
At the bottom of the flow, the following text should be included, e.g.
NOTE 2: Procedure steps (A) and (B) for GTP-based S2b are defined in clause x.
– In GTP based S2b call flows, each step for the relevant clause, belonging to say annex A, of the flow should be indicated by "A.1, A.2, …" . Common clauses of the flow should be indicated by shaded boxes with text referring to the PMIP based S2b call flow, e.g. "Procedures in Figure x.y.z-k, before A", "Procedures in Figure x.y.z-k, between A and B", etc.
Annex C (informative):
Handover Flows Between Non-3GPP Accesses