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.402  Word version:  18.3.0

Top   Top   Up   Prev   Next
0…   4…   4.2…   4.2.2   4.2.3   4.3…   4.4…   4.5…   4.5.7…   4.6…   4.7…   4.7.2…   4.8…   4.8.2a…   4.9…   5…   5.2…   5.4…   5.5   5.6…   5.7…   5.8…   6…   6.2…   6.3   6.4…   6.4.3…   6.5…   6.6…   6.7…   6.8…   6.10…   6.13…   6.15…   7…   7.2…   7.3   7.4…   7.5…   7.6…   7.8…   7.10…   8…   8.2.1.2   8.2.1.3…   8.2.2   8.2.3…   8.2.6…   8.3…   8.4…   8.5…   9…   9.3…   9.4…   10…   13…   16…   16.1.2…   16.1.6…   16.2…   16.2.1a…   16.3…   16.4…   16.7…   16.8…   16.10…   17…   A…   C…   E… 
4.3 Network Elements  4.3.1 Access Networks  4.3.2 MME  4.3.3 Gateway  4.3.4 ePDG  4.3.5 PCRF 
...

 

4.3  Network Elements  p. 29

4.3.1  Access Networks  p. 29

4.3.1.1  E-UTRAN  p. 29

E-UTRAN is described in detail in TS 36.300 with additional functions listed in TS 23.401.

4.3.1.2  Trusted and Untrusted Non-3GPP Access Network  p. 29

Trusted and Untrusted Non-3GPP Access Networks are IP access networks that use access technology whose specification is out of the scope of 3GPP.
Whether a Non-3GPP IP access network is Trusted or Untrusted is not a characteristic of the access network.
In non-roaming scenario it is the HPLMN's operator decision if a Non-3GPP IP access network is used as Trusted or Untrusted Non-3GPP Access Network.
In roaming scenario, the HSS/3GPP AAA Server in HPLMN makes the final decision of whether a Non-3GPP IP access network is used as Trusted or Untrusted non-3GPP Access Network. The HSS/3GPP AAA Server may take the VPLMN's policy and capability returned from the 3GPP AAA Proxy or roaming agreement into account.
For supporting multiple PDNs, the same trust relationship shall apply to all the PDNs the UE connects to from a certain Non-3GPP Access Network, i.e. it shall not be possible to access one PDN using the non-3GPP access network as Trusted, while access to another PDN using the same non-3GPP access network as Untrusted.
Up

4.3.2  MME  p. 30

The details of functionality of MME are described TS 23.401.
The following are additional MME functions:
  • HRPD access node (terminating S101 reference point) selection and maintenance for handovers to HRPD.
  • Transparent transfer of HRPD signalling messages and transfer of status information between E-UTRAN and HRPD access, as specified in the pre-registration and handover flows.
  • Forwarding the GRE key for uplink traffic to the target S-GW in case of CN node relocation.
  • Transparent transfer of SON Information between E-UTRAN and HRPD access.
Up

4.3.3  Gateway  p. 30

4.3.3.1  General  p. 30

Two logical Gateways exist:
  • Serving-GW (S-GW)
  • PDN-GW (P-GW)
The functional split of PDN-GW and Serving-GW is described in TS 23.401.

4.3.3.2  Serving-GW  p. 30

The functionality of the Serving-GW is described in TS 23.401. In addition to the functions described in TS 23.401 the Serving-GW includes the following functionality:
  • A local non-3GPP anchor for the case of roaming when the non-3GPP IP accesses connected to the VPLMN.
  • Event reporting (change of RAT, etc.) to the PCRF.
  • Uplink and downlink bearer binding towards 3GPP accesses as defined in TS 23.203.
  • Uplink bearer binding verification with packet dropping of "misbehaving UL traffic".
  • Mobile Access Gateway (MAG) according to PMIPv6 specification, RFC 5213, if PMIP-based S5 or S8 is used. The MAG function shall be able to send UL packets before sending the PBU or before receiving the PBA.
  • Decide if packets are to be forwarded (uplink towards PDN or downlink towards UE) or if they are locally destined to the S-GW (e.g. Router Solicitation).
  • DHCPv4 (relay agent) and DHCPv6 (relay agent) functions if PMIP-based S5 or S8 is used.
  • Handling of Router Solicitation and Router Advertisement messages as defined in RFC 4861, if PMIP based S5 and S8 is used.
  • Handling of Neighbour Solicitation and Neighbor Advertisement messages as defined in RFC 4861, if PMIP based S5 and S8 is used.
  • Allocation of downlink GRE key for each PDN connection within the Serving-GW, which is used by the PDN-GW to encapsulate downlink traffic to the Serving-GW on the PMIP-based S5/S8 interface.
  • If PMIP-based S8-S2a/b chaining is used:
    • the Serving-GW acts as a LMA towards the MAG function of the Trusted Non-3GPP IP Access or the ePDG;
    • the Serving-GW allocates uplink GRE key for each PDN connection within the Serving-GW, which is used to encapsulate uplink traffic on PMIPv6-based S2a/S2b interface.
    • the Serving-GW includes functionality to interwork the PMIPv6 signalling towards the PDN-GW and PMIPv6 signalling towards the MAG function of the Trusted Non-3GPP IP Access or the ePDG. In this case the Serving-GW also acts as a MAG towards the PDN-GW;
    • the Serving-GW includes functionality to link the user-plane of the PMIPv6 tunnel towards the PDN-GW and the user-plane of the PMIPv6 tunnel towards the MAG function of the Trusted Non-3GPP IP Access or the ePDG.
Up

4.3.3.3  PDN-GW  p. 31

PDN-GW functionality is described in TS 23.401 for 3GPP accesses connected to the EPC via GTP-based and PMIP-based S5/S8 interface. The PDN-GW supports functionality specified in TS 23.401 that is common to both PMIP-based and GTP-based S5/S8 interfaces also for access to EPC via non-3GPP accesses.
Additionally, the PDN-GW is the user plane anchor for mobility between 3GPP access and non-3GPP access. For this, the PDN-GW includes the following functionality:
  • A LMA according to the PMIPv6 specification, RFC 5213, if PMIP-based S5 or S8, or if PMIP-based S2a or PMIP-based S2b is used. The LMA function shall be able to accept UL packets from any trusted MAG without enforcing that the source IP address must match the CoA in the MN BCE.
  • A DSMIPv6 Home Agent, as described in RFC 5555, if S2c is used.
  • Allocation of uplink GRE key for each PDN connection within the PDN-GW, which is used to encapsulate uplink traffic to the PDN-GW on the PMIP-based S5/S8, or PMIP-based S2a or PMIP based S2b interface.
  • A MIPV4 Home Agent, if S2a with MIPv4 FA CoA mode is used.
  • GPRS Tunnelling Protocol for the control plane and the user plane to provide PDN connectivity to UEs using non-3GPP accesses, if GTP-based S2a or GTP-based S2b is used.
Up

4.3.4  ePDG  p. 31

The functionality of ePDG includes the following:
  • Allocation of a remote IP address as an IP address local to the ePDG which is used as CoA when S2c is used;
  • Functionality for transportation of a remote IP address as an IP address specific to a PDN when S2b is used;
  • Routing of packets from/to PDN-GW (and from/to Serving-GW if it is used as local anchor in VPLMN) to/from UE; if GTP based S2b is used and if a single IPSec SA is established for the PDN connection, this includes routing of uplink packets based on the uplink packet filters in the TFTs assigned to the S2b bearers of the PDN connection. If multiple IPsec SA are established for the PDN connection, routing of uplink packet is based on the mapping between the IPsec SA and the corresponding S2b bearer;
  • Routing of downlink packets towards the IPsec SA associated to the PDN connection. if a single IPsec SA is used for the PDN connection (see clause 4.10.5.1); Routing of downlink packets towards the IPsec SA associated to the S2b bearer, if a separate IPsec SA per S2b bearer is used (see clause 4.10.5.2);
  • De-capsulation/Encapsulation of packets for IPSec and, if network based mobility (S2b) is used, for GTP or PMIPv6 tunnels;
  • Mobile Access Gateway (MAG) according to the PMIPv6 specification, RFC 5213, if PMIP based S2b is used;
  • Tunnel authentication and authorization (termination of IKEv2 signalling and relay via AAA messages);
  • Local mobility anchor within untrusted non-3GPP access networks using MOBIKE (if needed);
  • Transport level packet marking for downlink packets, e.g. based on DiffServ Code Points on S2b, and for uplink packets, e.g. by setting a DiffServ Code Point based on the receipt of the MPS subscription notification from the UE, according to clause 7.2.4, or based on QCI, and optionally the ARP priority level;
  • Enforcement of QoS policies based on information received via AAA infrastructure;
  • Lawful Interception.
  • Allocation of downlink GRE key for each PDN connection within the ePDG, which is used to encapsulate downlink traffic to the ePDG on the PMIPv6-based S2b interface.
  • Accounting for inter-operator charging according to charging principles specified in TS 32.240.
  • Interfacing OFCS through reference points TS 32.251 for EPC nodes.
  • When the UE and the ePDG supports the establishment of a separate IPsec SA per S2b bearer:
    • Establishing, where applicable, a new IPsec SA between ePDG and UE over SWu for every new dedicated bearer if the UE supports multiple IPsec SAs per PDN connection.
    • Maintaining binding between EPC bearer ID and IPsec SA, where applicable. The default bearer maps to the initial IPsec SA.
Up

4.3.5  PCRF  p. 32

The functionality of PCRF is described in TS 23.203 with additional functionality listed in TS 23.401. In the non-roaming scenario, additionally, the PCRF terminates the Gxa, Gxb and Gxc reference points with the appropriate IP-CANs.
In roaming scenarios, the difference from TS 23.401, is that the vPCRF exists for the UE for the scenario of roaming with home-routed traffic in addition to the scenario in TS 23.401 of roaming with local breakout.
Up

4.3.5.1  Home PCRF  p. 32

In addition to the h-PCRF functionality listed in TS 23.401, in this document the Home PCRF
  • Terminates the Gx reference point for roaming with home routed traffic;
  • Terminates the Gxa, Gxb or Gxc/S9 reference points as appropriate for the IP-CAN type.

4.3.5.2  Visited PCRF  p. 32

In addition to the v-PCRF functionality listed in TS 23.401, in this document the Visited PCRF
  • Terminates the Gxa, Gxb or Gxc reference points as appropriate for the IP-CAN type;
  • Terminates the S9 reference point.

Up   Top   ToC