DL MIMO efficiency enhancements for LTE

DL MIMO efficiency enhancements for LTE

  November 16, 2020    tls123

---

MIMO is an effective technique to improve spectral efficiency and increase overall network capacity. SRS can be utilized to improve DL MIMO performance, especially for massive MIMO in TDD. In release-16 SRS capacity and coverage are enhanced by introducing more than one SRS symbol in a UL normal subframe and introducing virtual cell ID for SRS.

More than one symbol for SRS in a UL normal subframe

With the introduction of more than one SRS symbol in a UL normal subframe, the SRS capacity and coverage can be increased. These additional SRS symbol(s) are referred to as trigger type 2 SRS.

1 to 13 symbols of the first 13 symbols of a UL normal subframe can be configured to a UE for aperiodically triggered SRS transmission. Intra-subframe repetition, frequency hopping and antenna switching of the additional SRS symbols can be supported. A guard period of one SC-FDMA symbol can be configured for frequency hopping and antenna switching.

The number of repetitions can be configured from the set {1, 2, 3, 4, 6, 7, 8, 9, 12, 13}. If a UE has more receive antennas than transmit chains (e.g. 1T2R), the UE can be configured to transmit the additional SRS with antenna switching. And a UE can additionally be configured with frequency hopping for the additional SRS. The number of antennas (pairs) to switch is:

-    2 for 1T2R, or the number of pairs is configured as 2 for 2T4R

-    3 if the number of pairs is configured as 3 for 2T4R

-    4 for 1T4R

Both legacy SRS and additional SRS can be configured to the same UE, and transmission of legacy SRS and additional SRS symbol(s) in the same subframe for the UE is supported.

For sequence generation, per-symbol group hopping and sequence hopping are supported.

Independent open loop and close loop power control is supported for additional SRS, and DCI formats 3/3A/3B are used for close loop power control.

UEs not configured with SPUCCH/SPUSCH are not expected to be triggered with additional SRS in the same subframe as PUSCH/PUCCH in the same serving cell. UEs configured with SPUCCH/SPUSCH drop the SRS transmission in the symbols colliding with SPUCCH/SPUSCH in the same serving cell.

The additional SRS transmission in the symbols colliding with PUSCH/PUCCH of another serving cell in the same TAG, the same band and with the same CP, is dropped.

The additional SRS transmission in the symbols colliding with PUSCH/PUCCH of another serving cell in the different TAG is dropped if the total transmission power exceeds the PCMAX in any overlapping portion.

Virtual cell ID

Virtual cell ID within the range from 0 to 503 can be configured for SRS to increase SRS capacity.

The virtual cell ID can be configured to only additional SRS symbol(s) or both legacy and additional SRS symbol(s). If virtual cell ID is not configured, the physical cell ID is used.

Read More

Optimisations of UE radio capability signalling

Optimisations of UE radio capability signalling

  November 16, 2020    tls123

---

UE Radio Capability ID

UE Capability Segmentation

Background

With the increase in the size of UE radio capabilities driven by additional supported bands, the size of the UE Radio Capabilities will significantly grow from Rel-15 onwards, therefore an efficient approach to signal UE Radio Capability information was needed.

UE Radio Capability ID

The system optimisations for the 5GS (documented in TS 23.501) and for the EPS (documented in TS 23.401), that apply to both NR and E-UTRA, but not NB-IoT, consisting of using UE Radio Capability IDs as an alternative to signaling the UE Radio Capabilities container in system procedures:

-  between the UE and the CN (over Uu)

- between the CN and the RAN (impacting N2/S1 interfaces)

-  within the RAN in e.g. the handover procedures (impacting Xn/X2/S1/N2 interfaces)

-  within the CN.

The UE Radio Capability ID format is defined in TS 23.003. The UE Radio Capability ID is signaled by the UE in NAS as specified in TS 24.501 for the 5GS and as specified in TS 24.301 for the EPS. Two possible options for the assignment of UE Radio Capability ID exist:

-  Manufacturer-assigned: The UE Radio Capability ID may be assigned by the UE manufacturer in which case it includes a UE manufacturer identification (i.e. a Vendor ID). In this case, the UE Radio Capability ID uniquely identifies a set of UE radio capabilities for a UE by this manufacturer in any network.

-  Network-assigned: If a manufacturer-assigned UE Radio Capability ID is not used by the UE or the serving network, or it is not recognised by the serving network’s UE Capability Management Function (UCMF), the UCMF may allocate UE Radio Capability IDs for the UE corresponding to each different set of UE radio capabilities which the network may receive from the UE at different times. In this case, the UE Radio Capability IDs which the UE receives are applicable to the serving network and uniquely identify the corresponding sets of UE radio capabilities in this network. The network-assigned UE Radio Capability ID includes a Version ID in its format. The value of the Version ID is the one configured in the UCMF, at the time when the UE Radio Capability ID value is assigned. The Version ID value makes it possible to detect whether a UE Radio Capability ID is current or outdated.

 

UE Radio Capability IDs and the mapping to the corresponding UE radio capabilities are stored in a new function called the UE Capability Management Function (UCMF) in the CN. The UCMF is used for:

- storage of dictionary entries corresponding to either Network-assigned or Manufacturer-assigned UE Radio Capability IDs.

- assigning Network-assigned UE Radio Capability ID values.

-  provisioning of Manufacturer-assigned UE Radio Capability ID entries in the UCMF performed from an AF that interacts with the UCMF either directly or via the NEF/SCEF (or via Network Management).

    

UCMF architecture and related reference points in 5GS (left) and EPS (right)

System procedures are defined for 5GS in TS 23.502 and for EPS in TS 23.401.

UE Capability Segmentation

The RAN work item [10] calls for specification of a segmentation mechanism, so that in cases of excessively large UE capability signalling (e.g. capability information messages exceeding the maximum size of a PDCP SDU), the capability can be segmented into multiple RRC messages.  Segmentation applies to both NR and E-UTRA.

Segmentation is performed in the RRC protocol layer, with a separate RRC PDU for each segment.  The UE encodes the capability information message, then divides the encoded message into segments such that the size of each segment does not exceed the maximum size of a PDCP SDU (8188 octets in E-UTRA, 9000 octets in NR); the RAN node (eNB or gNB) receives the segments and reassembles them to reconstruct the original capability information message.  Segmentation is applied only in case the size of the encoded capability information message exceeds the maximum size of a PDCP SDU.  The signalling formats support up to 16 segments for a single capability information message.

Read More

Network Slicing

Network Slicing

  November 16, 2020    tls123

---

 Release 16 Network Slicing addresses two major limitations of Release 15 in 5GC:

(1) Enhancement of interworking between EPC and 5GC when UE moves from EPC to 5GC, the target serving AMF may not be able to serve all the PDU sessions that the UE intends to move to the 5GC.  More specifically, the following aspects needs to be addressed:

-              Selecting an AMF based on the slices associated to the active PDU connections that serve the UE in the EPC in Connected mode and during the Idle mode mobility

-              Selecting an appropriate serving V-SMF based on the slices associated to the active PDN connections that serve the UE in the EPC in Connected Mode

 (2) Support for Network Slice Specific Authentication and Authorization (NSSAA)

-              Enable the support for separate authentication and authorization per Network Slice.  The trigger of NSSAA in the 5GC is based on UE subscription information from UDM and also operator’s policy.  However, the UE shall indicate its support for NSSAA to its serving 5GC.

-              The AMF performs the role of the EAP Authenticator and communicates with the AAA-S via the AUSF. The AUSF undertakes any AAA protocol interworking with the AAA protocol supported by the AAA-S.

Enhancement of Interworking Between EPC and 5GC

During the mobility from EPS to 5GS, in case of CM-IDLE state, the PGW-C+SMF sends PDU Session IDs and related S-NSSAIs to AMF in Registration procedure. The AMF derives S-NSSAI values for the Serving PLMN and determines whether the current AMF is appropriate to serve the UE. If not, the AMF reallocation may need to be triggered. For each PDU Session the AMF determines whether the V-SMF need to be reselected based on the associated S-NSSAI value for the Serving PLMN. If the V-SMF need be reallocated, the AMF trigger the V-SMF reallocation.

In case of CM-CONNECTED state, during handover preparation phase the PGW-C+SMF sends PDU Session IDs and related S-NSSAIs to AMF. Based on the received S-NSSAIs values, the target AMF derives the S-NSSAI values for the Serving PLMN, the target AMF reselects a final target AMF if necessary and forwards the handover request to the final target AMF. When the Handover procedure completes successfully, the UE proceeds with the Registration procedure. For each PDU Session based on the associated derived S-NSSAI values, if the V-SMF need be reallocated, the final target AMF triggers the V-SMF reallocation. The final target AMF sends the S-NSSAI value for the Serving PLMN to V-SMF to update the SM context. The V-SMF updates NG RAN with the S-NSSAI value for the Serving PLMN via N2 SM message.

 

Network Slice-Specific Authentication and Authorization (NSSAA)

In Release-16, based on UE’s 5GMM Core Network Capability and subscription information, the serving AMF will trigger Network Slice-Specific Authentication and Authorization for the S-NSSAIs of the HPLMN. If a UE does not support this feature but requests these S-NSSAIs that are subject to Network Slice-Specific Authentication and Authorization, these S-NSSAIs will be rejected by the PLMN.

If a UE supports this feature and requests these S-NSSAIs, which are subject to Network Slice-Specific Authentication and Authorization, the UE shall leverage the corresponding credentials for these S-NSSAIs for the Network Slice-Specific Authentication and Authorization. As for how to these credentials in the UE are not specified.

To perform the Network Slice-Specific Authentication and Authorization for an S-NSSAI, the AMF invokes an EAP- based Network Slice-Specific authorization procedure for the S-NSSAI.

This procedure can be invoked for a supporting UE by an AMF at any time, e.g. when:

a.            The UE registers with the AMF and one of the S-NSSAIs of the HPLMN which maps to an S-NSSAI in the Requested NSSAI is requiring Network Slice-Specific Authentication and Authorization; or

b.            The Network Slice-Specific AAA Server triggers a UE re-authentication and re-authorization for an S-NSSAI; or

c.            The AMF, based on operator policy or a subscription change, decides to initiate the Network Slice-Specific Authentication and Authorization procedure for a certain S-NSSAI which was previously authorized.

Based on the outcome of the Network Slice-Specific Authentication and Authorization, the Allowed NSSAI for each Access Type will be updated accordingly.   It is network policies to decide for which Access Type to be used if both Access Types are subject for the Network Slice-Specific Authentication and Authorization. However, if the Network Slice-Specific Authentication and Authorization fails for all S-NSSAIs in the Allowed NSSAI, the AMF shall execute the Network-initiated Deregistration procedure with the appropriate rejection cause value for each Rejected S-NSSAI.

After a successful or unsuccessful UE Network Slice-Specific Authentication and Authorization, the UE context in the AMF shall retain the authentication and authorization status for the UE for the related specific S-NSSAI of the HPLMN while the UE remains RM-REGISTERED in the PLMN, so that the AMF is not required to execute a Network Slice-Specific Authentication and Authorization for a UE at every Periodic Registration Update or Mobility Registration procedure with the PLMN.

A Network Slice-Specific AAA server may revoke the authorization or challenge the authentication and authorization of a UE at any time. When authorization is revoked for an S-NSSAI that is in the current Allowed NSSAI for an Access Type, the AMF shall provide a new Allowed NSSAI to the UE and trigger the release of all PDU sessions associated with the S-NSSAI, for this Access Type.

The AMF provides the GPSI of the UE related to the S-NSSAI to the AAA Server to allow the AAA server to initiate the Network Slice-Specific Authentication and Authorization, or the Authorization revocation procedure, where the UE current AMF needs to be identified by the system, so the UE authorization status can be challenged or revoked.

The Network Slice-Specific Authentication and Authorization requires that the UE Primary Authentication and Authorization of the SUPI has successfully completed. If the SUPI authorization is revoked, then also the Network Slice-Specific authorization is revoked.

Read More

5GC location Services

5GC location Services

  November 16, 2020    tls123

---

Enhancement to the 5GC Location Services

The Location Services, specified in TS 23.273, include aspects of both regulatory and commercial nature.

The architecture and signalling procedures in NG-RAN are defined in TS 38.305.

Following aspects have been specified for 5G Location Services:

-    Service based 5G location architecture, including roaming and non-roaming, Function description of per Network Functions, etc.

-    General Concepts, e.g. Type of Location Requests, LCS Quality of services;

-    High Level Features, e.g. LMF selection, UE LCS privacy handling;

-    Location Service Procedures, which includes

-     5GC-MT-LR Procedure

-     5GC-MO-LR Procedure

-     Deferred 5GC-MT-LR Procedure for Periodic, Triggered and UE Available Location Events

-     LMF Change Procedure

-     Unified Location Service Exposure Procedure

-     Low Power Periodic and Triggered 5GC-MT-LR Procedure

-     Bulk Operation of LCS Service Request Targeting to Multiple UEs

-     Procedures to Support Non-3GPP Access

-     Procedures dedicated to Support Regulatory services

-     UE Assisted and UE Based Positioning Procedure

-     Network Assisted Positioning Procedure

-     Obtaining Non-UE Associated Network Assistance Data

-     UE Location Privacy Setting Procedure

-     Procedures with interaction between 5GC and EPC

-     Support of Concurrent Location Request;

-    Network Function Services, e.g. LMF services, GMLC services.

Read More

LTE in high speed

LTE in high speed

  November 15, 2020    tls123

---

 In Rel-13 and 14, the mobility and throughput performance were enhanced to cover high speeds (up to 350 km/h) by specifying the requirements for UE RRM, UE demodulation and base station demodulation, considering the two types of operator’s practical deployments shown in Figures 1 and 2. Figure 1 shows the case where no specific installation is deployed to handle high-speed trains, i.e. UEs in the train use the "standard" LTE eNBs. Alternatively, figure 2 shows the case where Single Frequency Network (SFN) are deployed. SFNs use so-called "Remote Radio Heads" (RRH), which are dedicated antennas deployed along the train track. In this case, the baseband unit (BBU) is connected to the RRH, e.g. using fiber.

Fig.1: Non-Single Frequency Network (SFN) high speed scenario

 

Fig2: SFN high speed scenario

These Rel-13 and 14 enhancements were conducted both for non-SFN and for SFN, but only for LTE single carrier, i.e. not covering Carrier Aggregation (CA).

Rel-16 improves the mobility and throughput performance, now considering CA and speeds up to 500 km/h. To this aim, it enhances RRM, UE demodulation and base station demodulation: it specifies enhanced RRM core requirements and corresponding RRC signals in respectively TS 36.133 and TS 36.331.

 

RRM requirements enhancements:

In Release 14 cases (limited to 350 km/h and single carrier), the latency requirements under DRX configuration up to 1.28s DRX cycle were enhanced by reducing the cell identification delay in connected mode and cell reselection delay in idle mode [1].

In Rel-16, considering Carrier Aggregation and speeds up to 500km/h, the following enhanced requirements were introduced to achieve good mobility performance and less paging outage:

1.    Enhanced RRM requirements for active SCells (for 350km/h velocity): The same requirements specified in Rel-14 high speed WI are applied to active SCells.

2. Enhanced RRM requirements for deactivated SCells (for 350km/h velocity): The cell identification delay and measurement period are reduced.

3.  Enhanced RRM requirements in DRX in connected mode (for 500km/h velocity):  The cell identification delay and measurement period on 1.28s DRX cycle are further reduced from those in Rel-14 high speed WI.

4.      Enhanced RRM requirements in idle mode (for 500km/h velocity): The cell detection delay is further reduced from those in Rel-14 high speed WI.

5.    Enhanced UL timing adjustment requirements in connected mode (for 500km/h velocity): The larger maximum autonomous time adjustment step is applied when the downlink bandwidth is wider than 10MHz.

 

Demodulation enhancements

6.      For UE and base station demodulation enhancements: In Release 14, UE and base station demodulation requirements were enhanced, for both cases of operator’s practical deployments shown in figures 1 and 2.

In Release 16, regarding the CA case in SFN (figure 2), the requirements specified in Rel-14 are expanded to Dual Connectivity's Secondary Cells (SCells) as defined in TS 36.331. Regarding further high speed up to 500 km/h, additional requirements are introduced to ensure the PDSCH/PUSCH/PRACH demodulation performance with larger Doppler shift.

Read More

ATSSS support in 5g

ATSSS support in 5g

  November 15, 2020    tls123

---

Coexistence with Non-3GPP systems: ATSSS

The ATSSS feature enables a multi-access PDU Connectivity Service, which can exchange PDUs between the UE and a data network by simultaneously using one 3GPP access network and one non-3GPP access network and two independent N3/N9 tunnels between the PSA and RAN/AN. The multi-access PDU Connectivity Service is realized by establishing a Multi-Access PDU (MA PDU) Session, i.e. a PDU Session that may have user-plane resources on two access networks, as shown on the figure below, extracted from TR 23.793. 

MA PDU session

These following procedures are defined in the context of this Feature:

-   Access Traffic Steering: it selects an access network for a new data flow and transfers the traffic of this data flow over the selected access network. Access traffic steering is applicable between one 3GPP access and one non-3GPP access.

-  Access Traffic Switching: it moves all traffic of an ongoing data flow from one access network to another access network in a way that maintains the continuity of the data flow. Access traffic switching is applicable between one 3GPP access and one non-3GPP access.

-   Access Traffic Splitting: it splits the traffic of a data flow across multiple access networks. When traffic splitting is applied to a data flow, some traffic of the data flow is transferred via one access and some other traffic of the same data flow is transferred via another access. Access traffic splitting is applicable between one 3GPP access and one non-3GPP access.

Key concepts of ATSSS supported in Release 16 include the following:

-   Multi-access PDU Session is a PDU Session that provides a PDU connectivity service, which can use one access network at a time, or simultaneously one 3GPP access network and one non-3GPP access network and two independent N3/N9 tunnels between the PSA and RAN/AN.

-    After the establishment of a MA PDU Session:

-    When there are user-plane resources on both access networks:

-    The UE applies network-provided policy (i.e. ATSSS rules derived by UE’s serving SMF based on ATSSS policy from serving PCF) and considers local conditions (such as network interface availability, signal loss conditions, user preferences, etc.) for deciding how to distribute the uplink traffic across the two access networks.

-    Similarly, the UPF anchor of the MA PDU Session applies network-provided policy (i.e. N4 rules derived by UE’s serving SMF based on ATSSS policy from serving PCF) and the feedback information received from the UE via the user-plane (such as access network Unavailability or Availability), the UPF then decides how to distribute the downlink traffic across the two N3/N9 tunnels and two access networks.

-    When there are user-plane resources on only one access network, the UE applies the ATSSS rules and considers local conditions for triggering the establishment or activation of the user plane resources over another access.

-  The type of a MA PDU Session may be one of the following types: i.e. IPv4, IPv6, IPv4v6, and Ethernet. The Unstructured type is not supported in Release 16.

-  The ATSSS feature can be supported over 3GPP and non-3GPP accesses, including untrusted and trusted non-3GPP access networks, wireline 5G access networks, etc., as long as a MA PDU Session can be established over the given type of access network

-     Two ATSSS steering functionalities are supported:

-     MPTCP functionality, for TCP traffic, with MPTCP proxy in UPF, by using the MPTCP protocol over the 3GPP and/or the non-3GPP user plane; and

-     ATSSS-LL functionality for all types of traffic, including TCP traffic, UDP traffic, Ethernet traffic, etc. ATSSS-LL functionality is mandatory for MA PDU Session of type Ethernet.

The following presents the example of the ATSSS traffic steering functionality within the UE.

Steering functionalities in an example UE model

-  The Performance Measurement Function (PMF) is supported by UPF and is specific for ATSSS-LL functionality, if enabled.  In Release 16, PMF supports two types of measurements between UE and UPF to assist access selection and they are:

-     UE and UPF make RTT measurements per access when the "Smallest Delay" steering mode is used; and

-     UE reports access availability/unavailability to UPF

The following presents the protocol stacks of the PMF for the user plane measurements over 3GPP and non-3GPP accesses respectively.

 

UE/UPF measurements related protocol stack for 3GPP access and for an MA PDU Session with type IP

In the case of an MA PDU Session with type Ethernet, the protocol stack over 3GPP access is that same as the one in the above figure, but the PMF protocol operates on top of Ethernet, instead of UDP/IP.

 

UE/UPF measurements related protocol stack for non-3GPP access and for an MA PDU Session with type IP

In the case of an MA PDU Session with type Ethernet, the protocol stack over non-3GPP access is that same as the one in the above figure, but the PMF protocol operates on top of Ethernet, instead of UDP/IP.

-   An ATSSS-capable UE may decide to request a MA PDU Session based on the provisioned URSP rules. In particular, the UE should request a MA PDU Session when the UE applies a URSP rule, which triggers the UE to establish a new PDU Session and the Access Type Preference component of the URSP rule indicates "Multi-Access".

-  The 5G QoS model for the Single-Access PDU Session is also applied to the MA PDU Session, i.e. the QoS Flow is the finest granularity of QoS differentiation in the MA PDU Session. One difference compared to the Single-Access PDU Session is that in a MA PDU Session there can be separate user-plane tunnels between the AN and the PSA, each one associated with a different access. The SMF shall provide the same QFI in 3GPP and non-3GPP accesses so that the same QoS is supported in both accesses. Non GBR QoS Flow can be distributed over 3GPP access and non 3GPP access, but GBR QoS Flow is transferred over single access.

- ATSSS is currently not supported when moving to EPC from 5GC, except for the specific case with wireline access integrated to EPC/5GC with 5G-RG; ATSSS with one User Plane leg in E-UTRA/EPC and one User Plane leg in wireline/5GC is supported.

Coexistence with Non-3GPP systems: Wireless and Wireline Convergence Enhancement

Read More

Wireless and Wireline Convergence Enhancement

Wireless and Wireline Convergence Enhancement

  November 15, 2020    tls123

---

Support of wireline access network

Support of Trusted Access network

Radio aspects 

Charging aspects

Coexistence with Non-3GPP systems: ATSSS

Support of wireline access network

The architecture for non-roaming is shown in figure 1, where the Wireline Access Gateway Function (W-AGF) is the access node performing the termination of N2 and N3 reference point, termination of access network interface Y4 and all access network specify functionalities, the relay of N1 to/from the UE., QoS enforcement, etc. The customer device, the UE, is replaced by the Residential Gateway which is augmented to support the 5G functionalities required to connect to 5G systems, such as NAS, URSP, PDU session, etc, called 5G-RG. The specification in TS 23.316 defines the modification to system architecture, procedure and flows, Policy and Charging Control for the 5G System in TS 23.501, TS 23.502 and TS 23.503.

The 5G-RG can also be connected via 3GPP Access basically by means of supporting the specification defined for UE. This scenario is called Fixed Wireless Access (FWA). Furthermore the 5G-RG may simultaneously connect to 3GPP Access and to wireline access by using the Single Access PDU session or supporting ATSSS feature. This scenario is called Hybrid scenario, using a terminology common on wireline access network. The ATSSS is supported as specified in TS 23.501, 23.502 and TS 23.503 where UE is replaced by 5G-RG and the Non-3GPP access is specifically referred to wireline access. In this latter case, TS 23.316 has also specified the support of interworking with EPC via 3GPP Access via a MA PDU session with a PDN Connection as user-plane resource associated with a MA PDU Session.

The support of legacy Residential Gateway not supporting 5G capability (FN-RG) is supported via W-AGF terminating the N1 NAS on behalf of UE and acting as a UE in respect the 5G core. 

In the case of Wireline Access Network defined in Broadband Forum the W-AGF functionalities is specified in BBF TR-470, BBF TR-456 and BBF TR-457, the 5G-RG is defined in BBF TR-124issue6 [8]. In the case of Wireline Access network defined in Cablelabs the W-AGF and 5G-RG functionalities are defined in CableLabs WR-TR-5WWC-ARCH.

Main impacts on the system by the WWC for wireline support are the following:

-    W-AGF: the access network function which performs the termination of N2 and N3 reference point, termination of access network interface Y4 and all access network specify functionalities, the relay of N1 to/from the UE. QoS enforcement, etc. When the W-AGF facing the FN-RG the W-AGF is supporting the termination of N1 NAS and performs the interworking between 5GC and the legacy wireline access network.

-    5G-RG: end user device replacing the UE which supports 5G capabilities (NAS protocol and procedure, USRP, IMSI, ATSSS) and extension of wireline access layer specific functionalities defined by Broadband forum and CableLabs. The 5G-RG may also support UE capability when connects via 3GPP Access.

-    FN-RG: end user device replacing the UE which does not support 5G capabilities.

-    Global Line Identifier (GLI): in case of wireline access based on BBF specifications this parameter uniquely identifies the line at which the 5G-RG in connected to within an operator domain.

-    Global Cable identifier (GCI): in case of wireline access based on CableLabs specification this parameter uniquely identifies the line at which the 5G-RG in connected to within an operator domain.

-    SUPI for FN-RG based on GCI and GLI.

-    All procedures defined in TS 23.502 have been modified to introduce the new network elements. The procedures are focused mainly on the part of specification that required improvements and to point out the access network interaction involving the W-AGF, 5G-RG and FN-RG to allow the Broadband Forum and CableLabs to develop the specifications under their responsibility.

-    IPTV support: The specification TS 23.316 in clauses 4.9.1 and 7.7.1 defines the support of IPTV via the support of multicast over unicast PDU session by using IGMP/MLD message send by STB via 5G-RG on PDU session and managed by UPF for adding the requiring 5G-RG to a multicast group and replicating the traffic received on N6 interface to the PDU session. The SMF is improved to control the support of IPTV by the UPF acting as PSA using PDR, FAR, QER, URR. This includes control of which IGMP and MLD requests the UPF is to accept or to deny.

-    QoS: the QoS model for wireline network is based on a subscription maximum aggregate bitrate including both GBR and Non-GBR traffic, hence the new parameter RG Total Maximum Bit Rate (RG-TMBR) has been defined. The RG-TMBR limits the aggregate bit rate that can be expected to be provided across all GBR and Non-GBR QoS Flows of a RG. The RG-TMBR is a parameter provided to the W-AGF by the AMF based on the value of the Subscribed RG-TMBR retrieved from UDM. The QoS control on wireline access network (i.e scheduling, rate limiting and traffic class management) is based on the line characteristic included in user subscription, for example different priority of service, different traffic class support by line of the single user, etc, for such reason the new parameter RG Level Wireline Access Characteristics (RG-LWAC) has been introduced. The format and content of RG LWAC is specified by BBF and it is transparently provided by UDM to AMF which may provide to the W-AGF at the time of the RG registration

-    mobility restriction based on GLI and GCI

-    support of BBF interaction with the Access Configuration System (ACS) to support the provisioning of configuration and remote management of 5G-RG as described in BBF TR-069 [12] or in BBF TR-369.

 Non- roaming architecture for 5G Core Network for 5G-RG with Wireline 5G Access network and NG RAN

Non- roaming architecture for 5G Core Network for FN-RG with Wireline 5G Access network and NG RAN

Support of Trusted Access network

The support of Trusted Network addresses the scenario where the Non-3GPP access network has a tighter relationship with 5GC in respect the untrusted scenario. However how the network is considered Trusted or Untrusted is not in the scope of this WID. The architecture for non-roaming is shown in figure 3, where the Trusted Non-3GPP Access Network (TNAN) is the access node performing the termination of N2 and N3 reference point, termination of access network interface, relay of N1 to/from the UE. From 3GPP point of view the TNAN network is composed by the TNGF and the Trusted Non-3GPP Access Point (TNAP) which are interconnected via the reference point Ta. However the detailed definition of TNAN and of Ta is beyond the WID scope. The reference point between the UE and the TNG, the NWt, is specified leveraging the IKEv2 defined for Untrusted. The main difference in contrast to Untrusted is in registration procedure, where it is assumed that EAP-5G can be carried between UE and TNAP directly on access layers, such on IEEE 802.11x and between TNAP and TNGF via Ta and not as part of IKEv2 establishment.  From other the point of view of other procedures, such as session management, the same procedure specified for Untrusted Non-3GPP access network can be used with basically the TNGF replacing the N3IWF, and modification that IKEv2 Child SA establishment is requested by TNGF and not by UE side.

Within the context of Trusted Non-3GP network, also the scenario of devices not supporting NAS connected via WLAN is specified. The role of TNGF is replaced the Trusted WLAN Interworking Function (TWIF) with the main difference that TWIF terminates the N1 NAS interface and it play the role of UE in respect the 5GC.

The specification is addressed in TS 23.501, TS 23.502 and TS 23.503

Non-roaming architecture for 5G Core Network with trusted non-3GPP access

Radio aspects 

The objective includes:

•  The description and enhancement of NG protocols to support the interface between the Trusted Non-3GPP Access Network and the 5GC;

•   The description and enhancement of NG protocols to support the interface between the Wireline 5G Access Network and the 5GC.

- from TS 29.413 and TS 38.413.

General radio aspects

-    Introduce the Trusted Non-3GPP Gateway Function (TNGF), Trusted WLAN Interworking Function (TWIF) to support the Trusted Non-3GPP Access, and Wireline Access Gateway Function (W-AGF) to support Wireline Access in TS 29.413 and TS 38.413.

-    Add the Global TNGF ID in the applicable NGAP messages between the TNGF and the AMF; add the Global TWIF ID in the applicable NGAP messages between the TWIF and the AMF; add the Global W-AGF ID in the applicable NGAP messages between the W-AGF and the AMF.

-    Add the selected PLMN Identity for trusted non-3GPP access and wireline access in Initial UE Message for Key derivation.

-    Add procedural texts that the Security Key IE may include KTNGF, or KTWIF, or KWAGF in TS 29.413.

 

Supporting the Trusted Non-3GPP Access with the 5GC – specific aspects

-    Add TNGF Identity Information, TWIF Identity Information in the UPLINK NAS TRANSPORT message containing a list of identifiers of NG-U terminations at TNGF/TWIF for UPF selection.

-    Add TNGF related and TWIF related User Location Information in the User Location Information IE.

 

Supporting the Wireline Access connectivity with the 5GC – specific aspects

-    Add W-AGF Identity Information in the UPLINK NAS TRANSPORT message containing a list of identifiers of NG-U terminations at W-AGF for UPF selection.

-    Add W-AGF related User Location Information in the User Location Information IE.

-    Add procedural texts to clarify the UE-AMBR is not used for wireline access in TS 29.413.

-    Add RG Level Wireline Access Characteristics in INITIAL CONTEXT SETUP REQUEST messages stored in the UE context by the W-AGF, indicating the wireline access technology specific QoS information corresponding to a specific wireline access subscription.

-    Add the Authenticated Indication in INITIAL UE MESSAGE to indicate that the FN-RG has been authenticated by the wireline 5G access network.

Charging aspects

The Wireless and Wireline Convergence for 5G system architecture (5WWC)is specified in TS 23.501, TS 23.502, TS 23.503 and TS 23.316. The enhancement to charging aspect for 5WWC is considered as part of this series specifications for this 5WWC.

Following charging scenarios are included in charging aspect of 5WWC as following:

-    UE Connects to 5G Core via Trusted Non-3GPP access

-    5G-RG connects to 5G Core via NR-RAN and via W-5GAN

-    FN-RG connects via W-5GAN.

The specifications related to 5WWC charging include TS 32.255, TS 32.291 and TS 32.298. The subscriber’s identifiers and PEI in 5G-RG and FN RG scenarios specified in TS 23.501 and TS 23.361 are used in charging information. The procedures and related triggers in 5WWC charging scenarios are also specified in charging aspect for 5WWC. The related changes to OpenAPI are specified in TS 32.291.

Read More