Method and apparatus for supporting a local area network (LAN) - Patents.com
By implementing new forwarding operations in the UPF to support local switch and Nx-based forwarding within 5G LANs, the solution addresses the lack of procedural details in current specifications, enhancing traffic routing efficiency and optimizing QoS enforcement.
Patent Information
- Application Number
- JP2023075794
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2019-02-18
- Filing Date
- 2023-05-01
- Publication Date
- 2024-12-19
- Estimated Expiration
- 2039-12-18
AI Technical Summary
Current 5G network specifications lack procedural details for implementing different routing policies such as N6-based, local switch-based, and Nx-based policies, leading to inefficiencies in traffic routing between user equipment within a 5G local area network (LAN).
The implementation of new forwarding operations in the User Plane Function (UPF) to support local switch and Nx-based forwarding, using Packet Forwarding Control Protocol (PFCP) signaling to enable direct traffic forwarding between UEs, even when served by different UPFs, without relying on external networks, and the use of new interface values to differentiate 5G-LAN traffic.
This approach enhances traffic routing efficiency within 5G LANs by allowing direct UE-to-UE traffic forwarding, optimizing QoS enforcement, and reducing reliance on external networks, thereby improving network resource utilization and reducing latency.
Smart Images

Figure 0007603098000002 
Figure 0007603098000003 
Figure 0007603098000004
Abstract
Description
[Technical field]
[0001]
[0001] Embodiments are disclosed that relate to control and user plane management for device-to-device communications within a local area network (LAN) (e.g., 5G LAN). [Background technology]
[0002]
[0002] 3GPP is currently standardizing the 5G core network as part of the overall 5G system architecture. FIG. 1 shows a 5G network architecture 100.
[0003]
[0003] From the access side, the 5G network architecture shown in FIG. 1 has multiple user equipments (UEs) (i.e., any device capable of wireless communication with the access network, including smartphones, smart appliances, sensors, and other Internet-of-Things (IoT) devices) connected to an access network (AN) (e.g., a Radio Access Network (RAN)), and the user equipments are connected to an Access and Mobility Management Function (AMF). Typically, the AN has base stations, such as evolved Node Bs (eNBs) and 5G base stations (gNBs). From the core network side, the 5G core network functions (NFs) shown in Figure 1 include NSSF (Network Slice Selection Function), AUSF (Authentication Server Function), UDM (Unified Data Management), AMF (Access and Mobility Management Function), SMF (Session Management Function), PCF (Policy Control Function), and AF (Application Function).
[0004]
[0004] In many ways, the 5G core network aims to separate the user plane and the control plane. The user plane generally carries user traffic, whereas the control plane carries signaling within the network. In Figure 1, the UPF is in the user plane, and all other network functions (NFs) shown, namely AMF, SMF, PCF, AF, AUSF, and UDM, are in the control plane. Separating the user plane and the control plane allows the resources of each plane to be scaled independently. It also allows the UPF to be deployed separately and distributed from the control plane functions. In this architecture, the UPF can be placed in close proximity to the UE to reduce the round trip time (RTT) between the UE and the data network for some applications that require low latency.
[0005]
[0005] The core 5G network architecture consists of modularized functions. For example, AMF and SMF are independent functions in the control plane. Separating AMF and SMF enables independent evolution and scaling. Other control plane functions such as PCF and AUSF can also be separated as shown in Figure 1. The modularized function design enables the 5G core network to flexibly support various services.
[0006]
[0006] The 5G network architecture reference point notation is used to develop a detailed flow in normative standardization.
[0007]
[0007] 3GPP SA2 has considered enhancing support for 5GS vertical and LAN services and has arrived at solutions, described in Sections 6.29 and 8.3 (portions of which are reproduced below), to serve as the basis for the standardization work.
[0008] 6.29 Solution X: Unified Architecture for 5G LAN-based Services 6.29.1 Functionality Description 6.29.1.1 Overview 5G LAN-based services are provided by a 5G system based on the architecture defined in Release 15 with the following extensions:
[0009] About the Centralized User Plane Architecture: - One SMF and one PSA UPF are responsible for all PDU sessions of 5G-LAN group communication. - The SMF is responsible for managing PDU sessions belonging to the 5G-LAN group (e.g., including managing the total number of established and activated PDU sessions). - All traffic of the members (i.e., UEs) of a participating 5G-LAN group passes through the PSA UPF, which must support QoS enforcement according to the R15 QoS architecture.
[0010] In case of a distributed user plane architecture, i.e. when PDU sessions of 5G-LAN group communication are controlled by one SMF and these PDU sessions may be terminated in one or several UPFs: - SMF enhancements: determining how traffic is routed (e.g., local switching between two UPFs via the Nx interface or N6 interface), and configuring packet processing rules (e.g., packet forwarding rules, packet marking rules) in the UPF to support 5G-LAN communications. - Introduced the Nx interface to connect two UPFs for routing traffic of 5G-LAN type services. The difference with the N9 interface is that the Nx interface has the granularity of the 5G-LAN group, which means that the Nx tunnel carries traffic belonging to the 5G-LAN group of communications.
[0011] 6.29.1.2 5G-LAN Group Management blank
[0012] 6.29.1.3 PDU Session Management 5G LAN Type Service The UE can access 5G LAN-based services by establishing a PDU session targeted to a DNN associated with the 5G-LAN group. A PDU session establishment request message (e.g., 5G LAN-VN DNN) is sent from the UE to the SMF as specified in Release 15. During the PDU session establishment, the SMF can contact the DN AAA to authenticate and authorize the UE for access to 5G LAN-based services to the intended 5G-LAN group. During PDU session establishment, the SMF determines the traffic routing method by associating all PDU session contexts targeting the same DNN associated with the 5G-LAN group (e.g., local switch, local switch between two UPFs via Nx interface or N6 interface).
[0013] 6.29.1.4 5G-LAN communication route management The SMF stores all PDU session contexts targeting the same DNN associated with the 5G-LAN group. The SMF stores the traffic routing policy of the 5G-LAN group obtained from the PCF or configured locally. There are various types of traffic routing policies for 5G-LAN communications, including: - N6-based, which means that all UL / DL traffic for 5G-LAN communications is routed to / from the DN. - Nx-based, which means that all UL / DL traffic of 5G-LAN communication is routed between PSA UPFs of different PDU sessions. - Local Switch: If a PSA UPF is common to different sessions, the traffic is routed locally by that UPF. The SMF generates PDU forwarding rules and provides them to the UPF. The UPF performs local traffic switching based on the extensions of the Release 15 mechanisms described in TS 23.501 [3] subclause 5.6.10.2 and 5.8.2.5. Alternatively, the PDR and FAR provide information that can explicitly indicate whether the uplink traffic flow is routed to the DN, to another PDU session anchor UPF (via the Nx interface), or locally routed. Packets of different 5G-LAN groups can be marked with respective VLAN tags by UPF.
[0014] 6.29.3 Impact on Existing Entities and Interfaces The SMF is extended to determine the traffic routing methodology for 5G-LAN type services. An Nx interface is optionally supported between the two UPFs to enable optimal routing for 5G-LAN type services. Local switching is supported by UPF. The N4 interface is extended so that the SMF instructs the UPF how to route traffic for 5G-LAN type services.
[0015] 6.29.4 Evaluation This solution supports N6-based, Nx-based, local switch-type traffic routing for 5G LAN-type services, which provides sufficient support to solve key issues 4 and 5.
[0016] 8.3.1 Conclusions for Key Issues #4 and #5 Solution #29 is concluded as a conclusion to key issues 4 and 5.
[0017] 8.3.2 Conclusion of Key Issue #4.1 on 5G-LAN Group Management a) In this release, it is assumed that 5G-LAN group management can be either configurable by a network administrator a.1) or dynamically managed by the AF a.2). For both a.1) and a.2): GPSI is used to uniquely identify 5G-LAN group members. For a.1) only: To identify the 5G-LAN group, the groups as described in clause 5.2.3.3.1 of TS 23.502 [4] are used. For a.2) only: For dynamic 5G-LAN group management, the NEF must expose a set of new service APIs for managing (e.g., adding / removing) 5G-LAN groups and 5G-LAN members. b) The 5G-LAN configuration is provided from the AF to the NEF using the NEF service operation information flow procedures described in TS 23.502 [4] clause 4.15.6.2 and stored in the UDR. c) The parameter list of the 5G-LAN configuration includes at least the PDU session type (i.e., IP or Ethernet), DNN, S-NSSAI and GPSI of the 5G-LAN group member UE (only in the case of a.2). Additional parameters for 5G-LAN configuration should be determined as part of the standardization work. d) The parts of the 5G-LAN configuration stored in the UDR, i.e. the PDU session type (IP or Ethernet), the DNN and the S-NSSAI, are delivered from the PCF to the UE using the UE configuration update procedure for transparent UE policy delivery described in clause 4.2.4.3 of TS 23.502 [4]. (Source: www.3gpp.org / ftp / / Specs / archive / 23_series / 23.734 / 23734-100.zip) US Patent Application Publication No. 2018192390 is considered to represent background art. US Patent Application Publication No. 2018192390 refers to a method of exchanging user plane (UP) management information between an application function (AF) supporting one or more applications and a slice management function (SMF) configured to manage traffic flows in a given slice of a network. The exchange of UP management information can be initiated by either the AF or the SMF. In the case of an AF-initiated information exchange, the UP management information provided by the AF can include traffic requirements of applications supported by the AF. In the case of an SMF-initiated information exchange, the UP management information provided by the SM can include operator policy information or events, and the AF may respond with information of traffic requirements of applications supported by the AF. Summary of the Invention
[0018]
[0008] Certain challenges exist, for example the lack of procedural details regarding when different routing policies are used (e.g. N6-based policy, local switch policy, and Nx-based policy).
[0019]
[0009] According to embodiments, the system and method enable the SMF to control new forwarding behavior in the UPF to support local switch and Nx-based forwarding. The solutions described herein also enable the UPF to efficiently handle direct forwarding between two Packet Forwarding Control Protocol (PFCP) sessions (aka N4 sessions), e.g., for "local switch."
[0020]
[0010] According to an embodiment, the SMF can configure the UPF using PFCP signaling so that the UPF can forward traffic from one UE to another UE when both UEs are served by the UPF ("local switch"), including receiving user plane traffic from a UE destined for another UE in the uplink direction, where the UPF can send traffic in the downlink direction to another UE associated with the same 5G-LAN group. This can be achieved without an external network DN, e.g. without N6.
[0021]
[0011] According to some embodiments, the SMF may configure two or more UPFs using PFCP signaling so that the UPFs can forward traffic from one UE to another UE when the UEs are served by different UPFs. This may be interpreted as "Nx-based forwarding". This may include receiving user plane traffic in a first UPF with a destination from one UE to another UE in an uplink direction, where the first UPF is instructed to forward the traffic to a second UPF, and the second UPF is instructed to transmit the traffic in a downlink direction to a destination UE associated with the same 5G-LAN group. In some examples, there may be one or more intermediate UPFs between the first UPF and the second UPF.
[0022]
[0012] In one aspect, a method for supporting a local area network (LAN (e.g., 5G LAN)) is provided. In one embodiment, the method includes a UPF receiving a transmission (e.g., a GTP-U PDU transmitted by an access network node or a PDU transmitted by another UPF over an Nx interface) including a protocol data unit (PDU) transmitted by a first user equipment (UE), the PDU including at least a destination address of a second UE. The method further includes the UPF using information included in the transmission to find a first packet detection rule (PDR) that matches the information included in the transmission (e.g., a source address and a destination address of the PDU), the first PDR identifying a first forwarding action rule (FAR), the first FAR including an indication (e.g., a destination interface set to "5G-LAN-internal") that indicates that the PDU requires further ingress processing (i.e., another PDR matching process is required for the PDU). The method further includes the UPF enforcing the first FAR (e.g., sending the PDU to a routing engine of the UPF using the network instance identifier and the 5G LAN internal interface to be included in the FAR so that the routing engine can perform another PDR matching process to find a second PDR for the PDU). The method further includes the UPF finding a second PDR for the PDU (e.g., the second PDR is found after identifying a second N4 session for the PDU and by matching the PDU with a packet detection information (PDI) included in the second PDR), where the second PDR identifies the second FAR. The method further includes the UPF enforcing the second FAR, where enforcing the second FAR includes using information included in the second FAR to forward the PDU to the second UE.
[0023]
[0013] In another embodiment, the method includes the UPF receiving a transmission (e.g., a GTP-U PDU transmitted by an access network node or a PDU transmitted by another UPF over an Nx interface) including a protocol data unit (PDU) transmitted by a first user equipment (UE), the PDU including at least a destination address of a second UE. The method further includes the UPF using information included in the transmission to find a first packet detection rule (PDR) that matches the information included in the transmission (e.g., a source address and a destination address of the PDU), the first PDR identifying a first forwarding action rule (FAR), the first FAR including an indication (e.g., a destination interface set to "5G-LAN-internal") that indicates that the PDU requires further ingress processing (i.e., another PDR matching process is required for the PDU). The method further includes the UPF obtaining the information included in the first FAR (e.g., reading a value of a destination interface IE included in the FAR). The method further includes, after the UPF obtains the information included in the first FAR, identifying the N4 session. The method further includes, after the UPF identifies the N4 session, finding a default PDR associated with the N4 session, the default PDR identifying a default FAR and / or a default URR, the default FAR configured to cause the UPF to send the PDU to a session management function (SMF), or the default URR configured to cause the UPF to send a PFCP Session Report Request message including at least a portion of the PDU (e.g., a destination IP address included in an IP header of the PDU) to the SMF.
[0024]
[0014] In another aspect, a method is provided that is performed by an SMF. In one embodiment, the method includes the SMF receiving a transmission sent by a first user plane function (UPF) as a result of the first UPF determining that the PDU is not routable, the PDU including a source address field including an address of the first UE and a destination address field including an address of the second UE, the transmission including 1) the PDU or 2) a PFCP Session Report Request message including the address of the second UE. The method further includes the SMF determining a UPF currently serving the second UE. The method further includes, after the SMF has determined a UPF currently serving the second UE, provisioning a PDR to the first UPF to enable the first UPF to route the PDU destined for the second UE towards the second UE.
[0025]
[0015] In another embodiment, the method includes the SMF generating a first Packet Detection Rule (PDR) associated with a first N4 session associated with a first UE or a 5G LAN group, the first PDR including a Forwarding Action Rule (FAR) identifier for identifying a first FAR. The method further includes the SMF generating a first FAR, the first FAR including an indication (e.g., a destination interface set to "5G-LAN-internal") that a PDU matching the first PDR requires further ingress processing (i.e., indicates that another PDR matching process is required for the PDU). The method further includes the SMF providing the first PDR and the first FAR to a first User Plane Function (UPF) (e.g., a UPF selected to serve the first UE).
[0026]
[0016] According to an embodiment, a network function may be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform (e.g., a cloud infrastructure). [Brief description of the drawings]
[0027]
[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments.
[0018] [Figure 1] FIG. 1 is a diagram illustrating a network architecture that may be used in accordance with an embodiment. [Figure 2A] FIG. 2A illustrates a scenario in which two UEs belonging to the same LAN group are served by the same UPF. [Figure 2B] FIG. 2B illustrates a scenario in which two UEs belonging to the same LAN group are served by different UPFs. [Figure 3A] FIG. 3A illustrates a scenario in which two UEs belonging to the same LAN group are served by the same UPF. [Figure 3B] FIG. 3B illustrates a scenario in which two UEs belonging to the same LAN group are served by different UPFs. [Figure 4] FIG. 4 is a flow chart illustrating a process according to an embodiment. [Diagram 5] FIG. 5 is a flow chart illustrating a process according to an embodiment. [Figure 6] FIG. 6 is a flow chart illustrating a process according to an embodiment. [Figure 7] FIG. 7 is a flow chart illustrating a process according to an embodiment. [Figure 8] FIG. 8 is a flow chart illustrating a process according to an embodiment. [Figure 9] FIG. 9 is a flow chart illustrating a process according to an embodiment. [Figure 10] FIG. 10 is a flow chart illustrating a process according to an embodiment. [Figure 11]FIG. 11 is a flow chart illustrating a process according to an embodiment. [Figure 12] FIG. 12 is a flow chart illustrating a process according to an embodiment. [Figure 13] FIG. 13 is a flow chart illustrating a process according to an embodiment. [Figure 14] 14 is an exemplary message flow diagram illustrating a system and process according to an embodiment. [Figure 15] FIG. 15 is a block diagram of an apparatus according to an embodiment. [Figure 16] FIG. 16 is an exemplary “call flow” illustrating processing in the UPF according to an embodiment. [Figure 17] FIG. 17 is an exemplary schematic diagram of a local switch in a UPF according to an embodiment.
[0028] [Figure 18] FIG. 18 is an exemplary schematic diagram of Nx-based forwarding in UPF according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0028] Detailed Description
[0029] In some examples, one or more of the following definitions may be used. 5G-LAN Group: A set of UEs that use private communication for 5G LAN type services. 5G LAN Type Service: A service on a 5G system that provides private communications using IP and / or non-IP type communications. 5G LAN Virtual Network: A virtual network capable of supporting 5G LAN type services. 5G-LAN one-to-one communication: Communication between two UEs in a 5G-LAN group. 5G-LAN one-to-many communication: communication between one UE and many UEs in a 5G-LAN group.
[0029]
[0030] There are some challenges with the current specifications for 5G, such as a lack of detailed procedures for using different routing policies (e.g., N6-based, local switch-based, and Nx-based). In certain aspects, there is a need to improve the routing of traffic between two UEs of a 5G-LAN group, such as by implementing local switch and / or Nx-based policies, without the need to use N6 to route traffic through an external data network (DN).
[0030]
[0031] According to an embodiment, Nx-based forwarding may require that UL / DL traffic is switched within the UPF between the N4 session for the PDU session (belonging to the 5G-LAN group member) and the shared tunnel (Nx) between the two UPFs. If there are QoS, usage reporting, etc. requirements associated with this shared tunnel, such as forcing all packets on the tunnel to a certain bit rate or counting the volume on the shared tunnel, the N4 session for the shared tunnel (PFCP session) can be used in addition to the N4 session for the PDU session. This allows specific QER and URR associated with the shared tunnel to be enforced. The SMF can instruct the UPF to forward traffic between the two N4 sessions within the UPF.
[0031]
[0032] According to an embodiment, a local switch in the UPF is provided. In some examples, local switch forwarding in the UPF may require UL / DL traffic to be switched in the UPF between an N4 session for a PDU session (belonging to a 5G-LAN group member) and another N4 session (belonging to another 5G-LAN group member). When performing local switch in the UPF, the UPF receives a UL packet of one PDU session, performs related processing (PDR, QER, URR, FAR), and transmits the packet as a DL transmission of another PDU session. Note that the egress of the UL processing can be connected to the ingress of the DL processing. For example, the FAR for a UL PDU can notify the UPF that the PDU requires further ingress processing (e.g., the FAR instructs the UPF to send the PDU back to its routing engine so that the UPF can match the PDU to another PDR).
[0032]
[0033] According to one embodiment, new values for "Source Interface" and "Destination Interface" are provided to represent interfaces internal to the UPF. For example, new values of "Internal", "5G-LAN", or a combination thereof ("5G LAN Internal") can be added to inform the UPF that the PDU requires further ingress processing. Current allowed values for Source Interface and Destination Interface information elements are: Access (0), Core (1), SGi-LAN / N6-LAN (2), CP Capability (3), LI Capability (4). See 3GPP TS 29.244 v.15.4.0 (hereinafter "TS 29.44"). Values 5-15 are not currently used. Thus, the new value (e.g., named 5G LAN Internal) can be an integer value greater than 4 and less than 16. In this embodiment, to ensure traffic separation between different 5G-LAN groups, a network instance information element (IE) (see TS 29.44, section 8.2.4) may be used to ensure that traffic from one 5G-LAN group is not mixed with traffic of another 5G-LAN group or with traffic not related to the 5G-LAN group. The network instance value may be set, for example, to a value that identifies a particular 5G-LAN group (e.g., 5G_LAN_group_01, 5G_LAN_group_02, 5G_LAN_group_03, ..., or 5G_LAN_group_01_Nx, 5G_LAN_group_02_Nx,).
[0033]
[0034] According to another embodiment, some new values for "Source Interface" and "Destination Interface" are provided to represent UPF-internal interfaces. These new source / destination interfaces may be named as "5G_LAN_Group01" (used for local switch when both communication parties (UEs) are served by the same UPF) and "5G_LAN_Group01_Nx" (used when both communication parties (UEs) are served by different UPFs), "5G_LAN_Group02" and "5G_LAN_Group02_Nx", "5G_LAN_Group03" and "5G_LAN_Group03_Nx" for different 5G LAN groups 01, 02, 03.
[0034]
[0035] According to an embodiment, in order to explicitly associate the two N4 sessions to the local switch, the PDU is not sent back for another round of ingress processing, such as classification based on the N4 session as well as the active PDR to identify the matching PDR. This is because the SMF already knows what the target N4 session is based on the destination address, which may lead to inefficiencies in some scenarios. Rather, and to instruct the UPF regarding the target N4 session and avoid inefficiencies, the UPF can determine the target N4 session based on packet inspection, and new values of source / destination interfaces can be used along with new parameters in the FAR indicating the target N4 session. For example, the FAR may include an N4 Session ID (SEID) corresponding to the PDU session to which the DL traffic is forwarded. The UPF would then know explicitly which N4 session to apply based on the FAR of the UL traffic and would not need to determine the N4 session again based on the PDR of the DL traffic. This may improve the efficiency of the UPF.
[0035]
[0036] 2A and 2B show first and second use cases according to an embodiment. The use case in Fig. 2A can be considered as a local switch, and the use case in Fig. 2B can be understood as an example of Nx-based forwarding.
[0036]
[0037] 2A, a system 200 is illustrated having one UPF 206 controlled by the SMF 208, for example, through an N4 session between the functions. The UPF node 206 serves UE-A 202 and UE-B 204. PDUs transmitted by the UEs may be received by a RAN node (e.g., gNB) (not shown in FIG. 2A) and then forwarded by the RAN node to the UPF 206. According to an embodiment, there is an N3 session established for each of the UEs 202, 204 with the UPF 206 via the RAN. The session may be defined and controlled by the SMF 208. There is also an N4 session for each of the UEs 202, 204.
[0037]
[0038] According to an embodiment, the SMF 208 configures the UPF 206 using PFCP signaling. In an aspect, the SMF 208 can provide the UPF with both a set of Packet Detection Rules (PDR) and a set of Forwarding Action Rules (FAR) that dictate how traffic from the UEs 202, 204 is handled. In this example, the UPF can forward traffic from one UE to another UE (e.g., UE-A 202 to UE-B 204) when both UEs are served by the same UPF ("local switch") and are part of a 5G-LAN group.
[0038]
[0039] In this configuration, the UPF 206 can forward traffic without a DN, e.g., without N6. However, since the UPF 206 has one or more PDRs / FARs for both UEs, it can apply the necessary rules without a DN. For example, for a communication from UE-A 202 to UE-B 204, the UPF 206 can (1) recognize that the traffic is intended for another UE served by the same UPF / group, (2) apply the appropriate action (e.g., QoS, counting and / or charging), and (3) apply the appropriate PDR / FAR to forward the traffic to the second UE-B 204. According to an embodiment, forwarding to the second UE-B 204 includes applying the appropriate PDR / FAR for that UE, including, e.g., appropriate QoS, counting and / or charging. In this regard, all rules are applied as if a DN was used on N6, without the need for a DN. This is also shown in FIG. 3A.
[0039]
[0040] 2B, a system 210 is illustrated with two UPFs, UPF1 206 and UPF2 214, both controlled by the SMF 208, e.g., via respective N4 sessions between the functions. As in the example of FIG. 2A, the UPFs 206, 214 handle communications with UEs 218, 220, respectively. According to an embodiment, there is a tunnel connection 222 between the UPFs 206, 214 (e.g., an Nx tunnel).
[0040]
[0041] According to some embodiments, the SMF 208 can instruct two or more UPFs, e.g., UPFs 206, 214, using PFCP signaling to allow the UPFs to forward traffic from one UE to another UE on the same LAN without using an external DN, e.g., via N6. This may include forwarding from UE 218 to UE 220 even if each UE is served by a different UPF. A tunnel connection 222 may be used for such "Nx-based forwarding". In this example, if UPF1 206 has user plane traffic from UE 218 with a destination towards another UE (e.g., UE 220) in the uplink direction, UPF1 206 is instructed to forward that traffic to the second UPF2 214, which is instructed to transmit the traffic in the downlink direction to the destination UE belonging to the same 5G-LAN group. This is further illustrated in FIG. 3B. Although not illustrated, in some examples, there may be one or more intermediate UPFs between the first UPF and the second UPF.
[0041]
[0042] In a particular aspect, the SMF 208 provides each of the UPFs 206, 214 with a set of both Packet Detection Rules (PDR) and Forwarding Action Rules (FAR), which dictate how traffic from each UE 218, 220 is handled. In this example, the first UPF can forward traffic from a first UE to a second UE (e.g., UE-A 218 to UE-B 220) using a tunnel connection 222 to the second UPF. In this configuration, the UPF can route traffic without using an external network DN, e.g., without using N6. However, since the UPF has the necessary PDR / FAR for each UE, the appropriate rules are applied. For example, for a communication from UE-A 218 to UE-B 220, the UPF 206 can (1) recognize the traffic as intended for another UE in the same group on another UPF, (2) apply appropriate actions (e.g., QoS, counting, and / or charging), and (3) apply the appropriate PDR / FAR to forward the traffic to the second UPF via the tunnel connection. According to an embodiment, the second UPF (e.g., UPF2 214) applies the appropriate PDR / FAR such that all appropriate actions are applied to the traffic. In this regard, no DN is required and all rules are applied as if a DN were used.
[0042]
[0043] According to an embodiment, a new forwarding table is created for the new destination interface. The destination indicator may be called, for example, "5G-LAN_GROUP" or "Internal". Such an indicator may enable the UPF to quickly look up "5G-LAN" in the forwarding table. Furthermore, in some embodiments, the UPF is informed that a PFCP session is applicable for 5G-LAN communication, so that the UE's address should be added to the forwarding table for "5G-LAN" upon PFCP session establishment for a given PDU session. This may be used to realize one or more of a local switch (as in FIG. 2A) and Nx-based forwarding (as in FIG. 2BA).
[0043]
[0044] According to an embodiment, a control plane function, e.g., SMF, controls one or more UPFs. In a particular aspect, the SMF can provide a UL PDR / FAR to send UE-to-UE traffic to the "5G-LAN". To identify UE-to-UE traffic from an originating UE, an uplink (UL) PDR may be provisioned either by a Service Data Flow (SDF) filter if the destination IP address is another UE's address, e.g., a range of destination IP addresses (in the address range reserved for the group), by an Ethernet packet filter if the destination MAC address is another UE's MAC address, or via a pre-configured application ID. This PDR detects packets from the originating UE that are destined for a particular target UE. A UL forwarding action rule (FAR) can be provisioned to forward traffic "inside the 5G-LAN". In a particular aspect, this FAR instructs the UPF to perform direct forwarding (e.g., "local switch" or "Nx-based forwarding") depending on the details in the FAR.
[0044]
[0045] Additionally, the control plane (e.g., SMF) may also provision a DL PDR / FAR to receive UE-to-UE traffic from the "5G-LAN". According to an embodiment, a DL PDR is provided to receive traffic from the "5G-LAN". In some embodiments, this PDR is the same as the one for forwarding DL traffic from SGi or N6. Also, a DL FAR may be provisioned to forward UE-UE traffic to a destination UE.
[0045]
[0046] The PDR / FAR for a particular UE and session in the UPF may be updated to accommodate traffic within the 5G-LAN. According to an embodiment, this may be accomplished by a "push" or "pull" type configuration between one or more UPFs and the SMF. For example, when a new UE joins the 5G-LAN group, an updated PDR / FAR may be pushed to the respective UPF for subsequent processing of messaging to / from such UE. In another example, one or more UPFs may obtain an updated (or initial) PDR / FAR for communication to / from a particular UE as needed upon recognition.
[0046]
[0047] As described above, when the UPF receives a packet sent by a first UE destined for a second UE on the same 5G-LAN as the first UE, the UPF identifies a first N4 session and matches the packet with a first PDR in the first N4 session. The first PDR indicates a first FAR for the packet, which indicates that the packet requires further ingress processing, thereby causing the UPF to search for a second PDR that matches the packet (e.g., the UPF identifies a second N4 session corresponding to the packet, and then searches for a PDR in the second N4 session that matches the packet). In some examples, a default PDR in the second N4 session may be defined with a minimum priority value to capture any unknown traffic. That is, when the UPF searches for the second PDR, the UPF may find that the default PDR is a matching PDR. In some embodiments, the default PDR indicates a FAR that instructs the UPF to forward the packet to the SMF. In another embodiment, the default PDR indicates a URR having a new reporting trigger, e.g., called “5G-LAN traffic”, which instructs the UPF to send a PFCP Session Report Request message to the SMF having at least a portion of the packet (e.g., at least the destination network address included in the network layer header of the packet).
[0047]
[0048] Upon receiving a packet or report request message, the SMF can look up which UPF is serving the destination UE and provide the associated PDR / FAR to the first UPF, and to any intermediate UPFs (for potential communication from the UE served by a UPF to the same destination UE), so that they can forward the traffic to that UPF.
[0048]
[0049] Figure 3A further illustrates an exemplary embodiment. In the example shown in Figure 3A, UE A transmits PDU 301 (e.g., IP packet) which is received by RAN 300. RAN 300 (e.g., a base station in the RAN) generates GTP-U PDU 303 including the GTP-U header and the PDU 301 transmitted by UE A by adding a GTP-U header to PDU 301. Then, RAN 300 transmits GTP-U PDU 303 to UPF 206, which receives the transmission (i.e., GTP-U PDU). PDU 301 includes the address of UE B as the destination address of PDU 301 (i.e., PDU 301 is destined for UE B). Then, the UPF 206 uses the information contained in the GTP-U PDU 303 to find a first PDR 304 that matches the information contained in the GTP-U PDU 303 (eg, the source address and destination address of the PDU sent by UE A).
[0049]
[0050] In some embodiments, finding the first PDR 304 using information included in the GTP-U PDU 303 includes using information included in the GTP-U PDU 303, e.g., a local tunnel endpoint identifier (TEID) identifying a tunnel endpoint at a receiving entity, previously assigned to a PDU session of UE A (for receiving the GTP-U PDU from the access network), to identify a first N4 session (e.g., an N4 session corresponding to the PDU 301 transmitted by the first UE) before finding the first PDR 304. The UPF 206 finds the first PDR by searching for a first matching PDR 304 in a set of PDRs 302 in the first N4 session (e.g., the UPF searches a set of one or more PDRs 302 in a prioritized order until it finds a PDR with a PDI that matches the PDU transmitted by UE A).
[0050]
[0051] The first PDR 304 identifies the first FAR 306 (i.e., the first PDR 304 includes a FAR ID that identifies the first FAR 306). The first PDR 304 may also specify one or more QoS Enforcement Rules (QERs) and / or one or more Usage Reporting Rules (URRs) 307, and the UPF applies the QERs and / or URRs with respect to the PDU 301.
[0051]
[0052] The first FAR 306 includes an indication (e.g., destination interface set to "5G-LAN internal") that the PDU 301 requires further ingress processing (i.e., another PDR matching process is required for the PDU 301). The UPF 206 then enforces the first FAR 306. For example, in some embodiments, enforcing the first FAR 306 includes the UPF 206 sending the PDU to a routing engine of the UPF using the network instance identifier and the 5G LAN internal interface as included in the FAR, so that the routing engine can perform another PDR matching process to find a second PDR 310 for the PDU 301 (the second PDR 310 may include a source interface IE set to "5G-LAN internal"). As discussed above, in one embodiment, the first FAR 306 includes a network instance IE that includes a network instance identifier that identifies a particular LAN group.
[0052]
[0053] For example, the routing engine when processing the PDU 301 again identifies a second N4 session for the PDU 301 and then searches the set of PDRs 308 in the second N4 session for a second matching PDR 310 (e.g., the UPF searches a set of one or more PDRs 308 in a prioritized order until it finds a PDR with a PDI that matches the PDU 301). The second matching PDR 310 indicates a second FAR 312. The second PDR 310 may also identify one or more QoS Enforcement Rules (QERs) and / or one or more Usage Reporting Rules (URRs) 314, and the UPF applies the QERs and / or URRs 314 with respect to the PDU 301.
[0053]
[0054] The UPF 206 then enforces the second FAR 312, where enforcing the second FAR includes the UPF 206 forwarding the PDU to UE B using information included in the second FAR (e.g., the value of the destination interface IE of the second FAR). In this example, the value of the destination interface IE of the second FAR is set to "access". In this regard, the PDU 301 is subject to the same rules as if the PDU for UE B was received via the N6 interface (i.e., from the data network (DN)). Before forwarding the PDU 301 to UE B, the UPF 206 adds a header to the PDU 301 based on the outer header creation information included in the second FAR 312, thereby generating a second GTP-U PDU 319 consisting of the outer header and the PDU 301. That is, when the UPF 206 transmits the GTP-U PDU 319 to the RAN 300, the RAN 300 forwards the PDU 301 to the UE B, and the UPF 206 forwards the PDU 301 to the UE B by transmitting the GTP-U PDU 319 to the RAN 300.
[0054]
[0055] FIG. 3B illustrates another exemplary embodiment. In the example illustrated in FIG. 3A, UE A transmits PDU 351 (e.g., IP packet) which is received by RAN 300. RAN 300 generates GTP-U PDU 353 including GTP-U header and PDU 351 by adding GTP-U header to PDU 351. RAN 300 then transmits GTP-U PDU 353 to UPF 206, which receives the transmission (i.e., GTP-U PDU). Note that PDU 351 includes UE C's address as a destination address (i.e., PDU 351 is destined for UE C). UPF 206 then uses information included in GTP-U PDU 353 to find a first PDR that matches the information included in GTP-U PDU 353 (e.g., source address and destination address of the PDU transmitted by UE A). In this example, the matching PDR is PDR 304.
[0055]
[0056] As described above, the first PDR 304 specifies the FAR 306 and may further specify one or more QoS enforcement rules (QERs) and / or one or more usage reporting rules (URRs) 307, and the UPF applies the QERs and / or URRs with respect to the PDU 351.
[0056]
[0057] As also described above, the first FAR 306 includes an indication that the PDU 351 requires further ingress processing (i.e., another PDR matching process is required for the PDU 351). The UPF 206 then enforces the first FAR 306. For example, in some embodiments, enforcing the first FAR 306 includes the UPF 206 sending the PDU 351 and a network instance identifier included in the FAR to a 5G LAN internal interface of a routing engine of the UPF so that the routing engine can perform another PDR matching process to find a second PDR 360 for the PDU 351 (the second PDR 360 may include a source interface IE set to "5G-LAN internal"). As described above, in one embodiment, the first FAR 306 includes a network instance IE that includes a network instance identifier that identifies a particular LAN group.
[0057]
[0058] For example, when processing the PDU 351 again, the routing engine identifies a second N4 session and then searches the set of PDRs 358 in the second N4 session for a second matching PDR 360 (e.g., the UPF searches a set of one or more PDRs 358 in a prioritized order until it finds a PDR with a PDI that matches the PDU 351). The second matching PDR 360 points to a second FAR 362. The second PDR 360 may also identify one or more QoS Enforcement Rules (QERs) and / or one or more Usage Reporting Rules (URRs) 364, and the UPF applies the QERs and / or URRs 364 with respect to the PDU 351.
[0058]
[0059] Then, the UPF 206 implements the second FAR 362, and implementing the second FAR includes the UPF 206 forwarding the PDU to the UE C using information included in the second FAR (e.g., a value of the destination interface IE of the second FAR). In this example, since the value of the destination interface IE of the second FAR is set to "5G LAN Nx", the UPF 206 forwards the PDU 351 to the UE C by sending the PDU 351 to the UPF 214. Specifically, before forwarding the PDU 351 to the UE C, the UPF 206 adds a header to the PDU 351 based on outer header creation information included in the second FAR 360, thereby generating a second GTP-U PDU 369 consisting of the outer header and the PDU 351. Then, UPF 206 transmits the GTP-U PDU 369 to UPF 214, which then forwards the PDU 351 to UE C via RAN 390, so that UPF 206 forwards the PDU 351 to UE C by transmitting the GTP-U PDU 369 to UPF 214.
[0059]
[0060] More specifically, upon receiving the GTP-U PDU 369, the UPF 214 uses information included in the GTP-U PDU 369 to find a PDR 196 that matches the information included in the GTP-U PDU 369 (e.g., the source address and destination address of the PDU sent by UE A). In some embodiments, the step of finding the PDR 196 using the information included in the GTP-U PDU 369 includes identifying a first N4 session (e.g., an N4 session corresponding to a 5G LAN group to which UE A and UE C belong) using information included in the GTP-U PDU 369, e.g., a local TEID, before finding the first PDR 196. The UPF 214 finds the PDR 196 by searching a set of PDRs 382 within the identified N4 session (e.g., the UPF 214 searches one or more sets of PDRs 382 in a prioritized order until it finds a PDR 196 having a PDI that matches the PDU 351).
[0060]
[0061] 4 is a flow chart illustrating a procedure 400 for supporting communication between a first UE, such as UE 202 (aka UE A), and a second UE, such as UE 204 (aka UE C) or UE 220 (aka UE C), camped on a local area network (LAN) (e.g., a 5G LAN), according to one embodiment. The procedure 400 is performed by the UPF 206. The procedure 400 may begin at step s402.
[0061]
[0062] Step s402 involves the UPF 206 receiving a transmission (e.g., a GTP-U PDU 303 sent by an access network node, or a PDU sent by another UPF over the Nx interface) including a PDU (e.g., PDU 301 or PDU 351) sent by UE A (hereinafter, a "UE PDU"), the UE PDU including at least a destination address of the second UE. In some embodiments, the transmission includes an outer header (e.g., a GTP-U header) to which the PDU 301 has been appended.
[0062]
[0063] Step s404 includes the UPF 206 using the information included in the transmission to find a first PDR (e.g., PDR 304) that matches the information included in the transmission (e.g., the source address and destination address of the UE PDU), where the first PDR identifies the first FAR (e.g., FAR 306). In some embodiments, the step of finding the first PDR using the information included in the transmission includes the UPF 206 using the information included in the transmission (e.g., a local TEID previously assigned to a PDU session of UE A (to receive GTP-U PDUs from the access network), or a local TEID previously assigned to an N4 session created for a particular 5G LAN group (to receive GTP-U PDUs from the first UPF) to identify a first N4 session (e.g., an N4 session corresponding to a 5G LAN group, or an N4 session corresponding to a PDU transmitted by UE A) before finding the first PDR, where the first PDR is associated with the identified N4 session. That is, after identifying the N4 session, the UPF matches the UE's PDU with the PDRs that are in the N4 session. In some embodiments, the first PDR includes instructions to remove the outer header (e.g., the GTP-U header to which the UE PDU was appended).
[0063]
[0064] In some embodiments, the first PDR includes a first PDI to enable UPF 206 to identify the PDU as relating to 5G LAN group traffic (e.g., the PDI defines source and destination address ranges, or one or more other significant bits within the PDU that can be used to identify the application used for communication within a given 5G LAN group).
[0064]
[0065] The first FAR includes an indication (e.g., a destination interface set to “5G-LAN Inside”) that the UE’s PDU requires further ingress processing (i.e., indicates that another PDR matching process is required for the PDU).
[0065]
[0066] In some embodiments, the first FAR further includes a network instance IE that includes a network instance value that identifies a particular 5G LAN group (i.e., the LAN group to which the first UE and the second UE belong).
[0066]
[0067] Step s406 includes the UPF 206 enforcing the first FAR (e.g., sending the PDU and the network instance identifier included in the FAR to a 5G LAN internal interface of a routing engine of the UPF so that the routing engine can perform another PDR matching process to find a second PDR for the PDU). In some embodiments, the Destination Interface IE of the first FAR includes an interface value (e.g., a value greater than 4 and less than 16), and the indication that the PDU requires further ingress processing is the interface value of the Destination Interface IE.
[0067]
[0068] Step s408 includes the UPF 206 finding a second PDR (e.g., PDR 310 or PDR 360) for the PDU, where the second PDR identifies a second FAR (e.g., FAR 312 or FAR 362). In some embodiments, the second PDR is found by identifying a second N4 session for the PDU and then matching the PDU with a packet detection information (PDI) included in the second PDR. In some embodiments, the second PDR includes a second PDI to match a source interface, e.g., an incoming PDU from inside a 5G LAN, with a network domain (e.g., IP domain) specific to traffic of a 5G LAN group identified by a network instance. In some embodiments, the second PDI includes at least a packet flow description in which a destination IP address is set to an IP address belonging to a second UE. In some embodiments, the second N4 session is an N4 session created for a PDU session of the second UE, or the second N4 session is an N4 session created for a specific 5G LAN group shared by all UEs associated with the same 5G LAN group, enabling communication of the UEs when the UEs are served by different UPFs.
[0068]
[0069] Step s410 includes the UPF 206 enforcing a second FAR, where enforcing the second FAR includes forwarding the PDU to the second UE using information included in the second FAR.
[0069]
[0070] In some embodiments, the UPF 206 serves the second UE, and forwarding the PDU to the second UE includes the UPF 206 forwarding the PDU to the access network node (e.g., a 5G-AN node) using a tunnel (e.g., an N3 GTP-U tunnel) established between the UPF 206 and the access network node. In such embodiments, the second FAR includes a Destination Interface IE that includes an interface value set to “Access” (i.e., set to 0).
[0070]
[0071] In some embodiments, forwarding the PDU to the second UE includes the UPF 206 forwarding the PDU to a second UPF (e.g., the UPF 214) (which may be a UPF serving the second UE or a UPF between the UPF 206 and a UPF serving the second UE) using a tunnel (e.g., an N9 GTP-U tunnel) established between the UPF 206 and the second UPF. In such embodiments, the second FAR may include a destination interface IE that includes an interface value (e.g., “5G LAN Nx”) indicating that the UPF should forward the PDU to the second UPF using the tunnel established between the UPF 206 and the second UPF.
[0071]
[0072] In some embodiments, the second FAR includes a destination interface IE that includes an interface value (e.g., “Core”) indicating that the UPF should forward the PDU to the packet data network via the N6 interface.
[0072]
[0073] In some embodiments, the second FAR further includes a network instance IE that identifies a network domain (e.g., an IP domain) specific to 5G LAN group traffic.
[0073]
[0074] In some embodiments, the second PDR includes a Source Interface IE that includes an interface value that is set to the same value as the interface value of the Destination Interface IE included in the first FAR, and the second PDR includes a Network Instance IE that includes a Network Instance value that is set to the same value as the Network Instance value of the Network Instance IE included in the first FAR.
[0074]
[0075] In some embodiments, the first PDR includes a usage reporting rule (URR) identifier that identifies a first URR and the second PDR includes a URR identifier that identifies a second URR, and the procedure 400 includes the UPF 206 applying the first URR with respect to the PDU and the UPF 206 applying the second URR with respect to the PDU. In such embodiments, the first URR may specify a method for measuring network resource usage, and applying the first URR with respect to the PDU includes measuring network resource usage with respect to the PDU.
[0075]
[0076] 5 is a flow chart illustrating a procedure 500 for supporting communication between a first UE, such as UE 202 (aka UE A), and a second UE, such as UE 204 (aka UE C) or UE 220 (aka UE C), camped on a local area network (LAN) (e.g., a 5G LAN), according to one embodiment. The procedure 500 is performed by the UPF 206. The procedure 500 may begin at step s502.
[0076]
[0077] Step s502 involves the UPF 206 receiving a transmission (e.g., a GTP-U PDU 303 sent by an access network node, or a PDU sent by another UPF over the Nx interface) (hereinafter "UE PDU") including a PDU sent by UE A (e.g., PDU 351), the UE PDU including at least a destination address of the second UE. In some embodiments, the transmission includes an outer header (e.g., a GTP-U header) to which the UE PDU has been appended.
[0077]
[0078] Step s504 includes the UPF 206 using information included in the transmission to find a first PDR (e.g., PDR 304) that matches the information included in the transmission (e.g., the source address and destination address of the UE PDU), where the first PDR identifies a first FAR (e.g., FAR 306). In some embodiments, the step of finding the first PDR using the information included in the transmission includes the UPF 206 identifying a first N4 session using information included in the transmission before finding the first PDR. That is, after identifying the N4 session, the UPF matches the UE PDU with a PDR that is in the N4 session.
[0078]
[0079] Step s506 includes the UPF 206 obtaining information included in the first FAR. For example, in step s506, the UPF 206 reads a value of a Destination Interface (DI) IE included in the FAR. In this example, the value of the DI IE indicates that the UE PDU requires further ingress processing (i.e., another PDR matching process is required for the PDU). After obtaining the information, the UPF 206 determines, based on the information, that further ingress processing is required for the UE PDU. As a result of determining that further ingress processing is required for the UE PDU, the UPF 206 determines an N4 session for the UE PDU (e.g., the UPF 206 determines an N4 session based on the information included in the UE PDU).
[0079]
[0080] Thus, step s508 includes the UPF 206 identifying the N4 session after obtaining the information contained in the first FAR.
[0080]
[0081] Step s510 includes that after identifying the N4 session, the UPF 206 finds a default PDR associated with the N4 session. More specifically, after identifying the N4 session, the UPF 206 checks whether the UE PDU matches any of the PDRs in the identified N4 session. The UE PDU matches a PDR if the information in the UE PDU (e.g., source address and / or destination address) matches the PDI included in the PDR. In this example, the UE PDU matches only the "default" PDR associated with the N4 session (i.e., the PDR in the N4 session with the lowest priority).
[0081]
[0082] The default PDR identifies a default FAR and / or a default URR. The default FAR is configured to cause the UPF to send the UE PDU to the SMF. The default URR is configured to cause the UPF to send a PFCP Session Report Request message including at least a portion of the PDU (e.g., a destination IP address included in the IP header of the PDU) to the SMF.
[0082]
[0083] In some embodiments, the procedure 500 may further include the UPF 206 sending the PDU to the SMF. After sending the PDU to the SMF, the UPF 206 receives a second PDR and a second FAR associated with the N4 session from the SMF, where the second PDR includes a FAR identifier that identifies the second FAR.
[0083]
[0084] In some embodiments, the procedure 500 may further include the UPF 206 sending a PFCP session report request message to the SMF. After sending the PFCP session report request message to the SMF, the UPF 206 receives a second PDR associated with the second N4 session and the second FAR from the SMF, where the second PDR includes a FAR identifier that identifies the second FAR.
[0084]
[0085] 6 is a flow chart illustrating a procedure 600 for providing rules to the UPF according to one embodiment. The procedure 600 is performed by the SMF. The procedure 600 may begin at step s602.
[0085]
[0086] Step s602 includes the SMF receiving a transmission sent by the first UPF as a result of the first UPF determining that the PDU is not routable, the PDU including a source address field that stores the address of the first UE and a destination address field that stores the address of the second UE, the transmission including 1) the PDU, or 2) a PFCP Session Report Request message that includes the address of the second UE.
[0086]
[0087] Step s604 includes the SMF determining a UPF currently serving the second UE.
[0087]
[0088] Step s606 includes the SMF, after identifying a UPF currently serving the second UE, provisioning a PDR to the first UPF to enable the first UPF to route PDUs destined for the second UE towards the second UE. In some embodiments, the PDR is in an N4 session created specifically for the 5G LAN group to which the first and second UEs belong.
[0088]
[0089] In some embodiments, the procedure 600 further includes the SMF provisioning a second PDR to the second UPF to enable the second UPF to route the PDU destined for the second UE and intended for the destination 5G LAN group towards the second UE. In some embodiments, the second PDR includes instructions to remove the outer header of the PDU received from the source interface 5G LAN Nx and the network domain specifics (e.g., IP domain) specified by the network instance, the second PDR is associated with the FAR. In some embodiments, the FAR includes a destination interface IE (e.g., "5G LAN-Inside") that includes an interface value, e.g., by sending the PDU to the routing engine of the UPF using the network instance identifier and the 5G LAN-Inside interface included in the FAR, the network instance is set to a value specific to the 5G LAN group indicating that the second UPF enforces the FAR, so that the routing engine can perform another PDR matching process to find another PDR in the second UE N4 session for the PDU.
[0089]
[0090] In some embodiments, the SMF generates the PDR based on the UPF currently serving the second UE. For example, if a different UPF than the first UPF is serving the second UE, the PDR will include a FAR identifier that identifies the FAR with the destination interface IE set to, for example, 5G LAN Nx and a network instance that identifies a network domain (e.g., IP domain) specific to 5G LAN group traffic, while if the first UPF is serving the second UE, the PDR will include a FAR identifier that identifies the FAR with the destination interface IE set to, for example, “access.”
[0090]
[0091] 7 is a flow chart illustrating a procedure 700 for providing rules to the UPF according to one embodiment. The procedure 700 is performed by the SMF. The procedure 700 may begin at step s702.
[0091]
[0092] Step s702 includes the SMF generating a first PDR associated with a first N4 session associated with the first UE or associated with the 5G LAN group, the first PDR including a FAR identifier for identifying the first FAR.
[0092]
[0093] Step s704 includes the SMF generating a first FAR, the first FAR including an indication (e.g., destination interface set to “5G-LAN inside”) that the PDU matching the first PDR requires further ingress processing (i.e., indicates that another PDR matching process is required for the PDU).
[0093]
[0094] Step s706 includes the SMF providing the first PDR and the first FAR to a first UPF (eg, a UPF selected to serve the first UE).
[0094]
[0095] In some embodiments, the SMF provides the first PDR to the first UPF by sending a session request (e.g., a session creation request or a session modification request) including the first PDR to the first UPF.
[0095]
[0096] In some embodiments, the procedure 700 further includes the SMF generating a second PDR associated with the second N4 session, the second PDR including a FAR identifier for identifying the second FAR, the SMF generating the second FAR, and the SMF providing the second PDR and the second FAR to the first UPF, where a destination interface IE of the second FAR is set to core, access, or 5G LAN Nx (e.g., a value greater than 4 and less than 16). In some embodiments, the second PDR is associated with an N4 session created for a particular 5G LAN group, and the destination interface IE of the second FAR is set to 5G LAN Nx. In some embodiments, the second PDR is associated with an N4 session associated with the second UE, and the destination interface IE of the second FAR is set to access. In some embodiments, the network instance IE of the second FAR is set to a value that identifies a network domain (e.g., IP domain) specific to 5G LAN group traffic.
[0096]
[0097] 8 is a flow chart illustrating a process 800 for supporting a LAN (e.g., a 5G LAN). The process 800 may begin at step s802.
[0097]
[0098] Step s802 includes generating a first packet detection rule (PDR) associated with the first user equipment (UE), the first PDR including a forwarding action rule (FAR) identifier for identifying the first FAR.
[0098]
[0099] Step s804 includes generating a first FAR, the first FAR including i) an indication (e.g., “internal” and / or “5G-LAN”) that at least a second PDR (e.g., an ingress PDR) should be applied to packets matching the first PDR (e.g., packets matching a packet detection information (PDI) included in the first PDR), and / or ii) an identifier (e.g., “internal”, “5G-LAN”, and / or an N4 session identifier) for use in identifying a set of one or more PDRs (e.g., a set of PDRs with a source interface attribute set to that identifier (e.g., set to “internal” or “5G-LAN”)). The set of one or more PDRs is associated with i) a second UE or ii) a tunnel between the first UPF and the second UPF, and / or the second PDR is associated with i) a second UE or ii) a tunnel between the first UPF and the second UPF. The PDI of the first PDR has one or more match fields against which packets are matched.
[0099]
[0100] Step s806 includes providing the first PDR and the first FAR to a first user plane function (UPF) selected to serve the first UE.
[0100]
[0101] Steps s802 to s806 are performed by the SMF in some embodiments.
[0101]
[0102] In some embodiments, the first FAR includes an identifier, the identifier included in the first FAR is an N4 session identifier that identifies an N4 session associated with the second UE, and each PDR included in the set of one or more PDRs includes the N4 session identifier.
[0102]
[0103] In some embodiments, the method is performed by a Session Management Function (SMF) that provides session management functionality for both the first UE and the second UE.
[0103]
[0104] In some embodiments, the SMF generates the first PDR and the first FAR after the second UE connects to the LAN.
[0104]
[0105] In some embodiments, the SMF provides the first PDR to the first UPF by sending a session modification request including the first PDR to the first UPF.
[0105]
[0106] In some embodiments, the procedure further includes the SMF receiving a transmission from the first UPF including an identifier (e.g., an IP address) associated with the second UE and identifying a UPF currently serving the second UE, where the SMF generates the first FAR based on the UPF currently serving the second UE.
[0106]
[0107] In some embodiments, the UPF serving the second UE is a second UPF, and the set of PDRs and / or the second PDR is associated with a tunnel between the first UPF and the second UPF.
[0107]
[0108] In some embodiments, the UPF serving the second UE is the first UPF, and the set of PDRs and / or the second PDR are associated with an N4 session identifier associated with the second UE.
[0108]
[0109] In some embodiments, the transmission from the first UPF includes an uplink (UL) packet transmitted by the first UE, the UL packet including an IP address assigned to the second UE.
[0109]
[0110] In some embodiments, the transmission from the first UPF includes a session report request message.
[0110]
[0111] In some embodiments, the FAR includes a destination interface attribute and the indication is a destination interface value (e.g., “internal” and / or “5G-LAN”) for the destination interface attribute.
[0111]
[0112] In some embodiments, the second PDR includes an indicator indicating that the second PDR applies to locally switched traffic (e.g., applies to packets having a source and destination on a LAN), and the method further includes providing the second PDR to the first UPF, or the set of PDRs includes a second PDR that includes an indicator indicating that the second PDR applies to locally switched traffic (e.g., applies to packets having a source and destination on a LAN), and the method further includes providing the second PDR to the first UPF.
[0112]
[0113] In some embodiments, the second PDR has a source interface attribute, and the indicator that the second PDR applies to the locally switched traffic is the value of the source interface attribute of the second PDR.
[0113]
[0114] In some embodiments, the first FAR includes i) an indication that at least a second PDR should be applied to packets that match the first PDR, and ii) an identifier (e.g., an N4 session identifier) for use in identifying a set of one or more PDRs, where the set of PDRs includes the second PDR.
[0114]
[0115] 9 is a flow chart illustrating a process 900 for supporting a LAN (e.g., a 5G LAN). The process 900 may begin at step S902.
[0115]
[0116] Step s902 includes a first user plane function (UPF) receiving a transmission including a protocol data unit (PDU) transmitted by a first user equipment (UE), (e.g., a GTP-U PDU transmitted by an access network node), the PDU including a destination address of a second UE.
[0116]
[0117] Step s904 includes a first user plane function using information included in the transmission (e.g., a destination address of the PDU) to identify a first rule (e.g., a packet detection rule (PDR)) for the PDU, the first rule identifying a first forwarding action rule (FAR).
[0117]
[0118] Step s906 comprises, after identifying the first rule, the first UPF searching for the first FAR.
[0118]
[0119] Step s908 includes the first UPF using information included in the first FAR to determine a second rule for the PDU, the second rule specifying a second FAR.
[0119]
[0120] Step s910 includes the first UPF searching for a second FAR after identifying the second rule.
[0120]
[0121] Step s912 includes the first UPF forwarding the PDU to the second UE using the information contained in the second FAR.
[0121]
[0122] Steps s902-s912 are performed by the UPF in some embodiments.
[0122]
[0123] In some embodiments, the first UPF serves the second UE and forwarding the PDU to the second UE includes the UPF forwarding the PDU to an access network node (e.g., a 5G-AN node) using a tunnel (e.g., an N3 GTP-U tunnel) established between the first UPF and the access network node.
[0123]
[0124] In some embodiments, the second UPF serving the second UE and forwarding the PDU to the second UE includes the first UPF forwarding the PDU to the second UPF using a tunnel (e.g., an N9 GTP-U tunnel) established between the first UPF and the second UPF.
[0124]
[0125] In some embodiments, forwarding the PDU to the second UE includes the first UPF forwarding the PDU to a packet data network (eg, using an N6 interface).
[0125]
[0126] In some embodiments, the first rule includes a Usage Reporting Rule (URR) identifier that specifies a first URR, and the second rule includes a Usage Reporting Rule (URR) identifier that specifies a second URR, and the method further includes (1) the first UPF applying the first URR with respect to the PDU, and (2) the first UPF applying the second URR with respect to the PDU. According to certain aspects, the first URR specifies a method for measuring network resource usage, and applying the first URR with respect to the PDU includes measuring network resource usage with respect to the PDU.
[0126]
[0127] In some embodiments, the method further includes the first UPF receiving a transmission sent by the UE, where the transmission includes a PDU storing a destination address of a third UE, the first UPF verifying that the PDU matches a default PDR storing a FAR identifier that identifies the third FAR, the first UPF searching for the third FAR, where the third FAR instructs the first UPF to forward the PDU to a session management function, and the first UPF forwarding the PDU to the SMF according to the instruction of the third FAR.
[0127]
[0128] In some embodiments, the method further includes the first UPF receiving a transmission sent by the UE, the transmission including a PDU storing a destination address of the third UE, the first UPF verifying that the PDU conforms to a default PDR including a rule identifier that identifies the URR, the first UPF retrieving the URR, the URR instructing the first UPF to send a report (e.g., the report including the destination address of the third UE) to the SMF, and the first UPF sending the report to the SMF as instructed by the URR.
[0128]
[0129] 10 is a flow chart illustrating a process 1000 for supporting a LAN (e.g., a 5G LAN). The process 1000 may begin at step s1002.
[0129]
[0130] Step s1002 includes generating a packet detection rule (PDR) that specifies a forwarding action rule (FAR), the PDR and / or FAR defining how to route traffic from a first user equipment (UE) in the LAN to a second UE in the LAN.
[0130]
[0131] Step s1004 includes providing the PDR to a User Plane Function (UPF), the UPF associated with the first UE and the second UE, the PDR and / or FAR enabling the UPF to apply ingress and egress operations (e.g., QoS, charging, and counting) to both the first UE and the second UE.
[0131]
[0132] Steps s1002 and s1004 are performed by the SMF in some embodiments.
[0132]
[0133] In some embodiments, the PDR and / or FAR define how to route the traffic from the first UE to the second UE without using an external data network (DN) (eg, via N6).
[0133]
[0134] 11 is a flow chart illustrating a process 1100 for supporting a LAN (e.g., a 5G LAN). The process 1100 may begin at step s1102.
[0134]
[0135] Step s1102 includes generating a first packet detection rule (PDR) that specifies a forwarding action rule (FAR), the PDR and / or FAR defining how to route traffic from a first user equipment (UE) in the LAN to a second UE in the LAN.
[0135]
[0136] Step s1104 includes providing the PDR to a first user plane function (UPF), the UPF associated with the first UE, the FAR including one or more instructions for the first UPF to route the traffic to a second UPF via a tunnel connection between the first and second UPFs, the second UPF associated with the second UE.
[0136]
[0137] Steps s1102 and s1104 are performed by the SMF in some embodiments.
[0137]
[0138] In some embodiments, the PDR and / or FAR define how to route the traffic from the first UE to the second UE without using an external data network (DN) (eg, via N6).
[0138]
[0139] 12 is a flow chart illustrating a process 1000 for supporting a LAN (e.g., a 5G LAN). The process 1000 may begin at step s1202.
[0139]
[0140] Step s1202 includes a first user plane function (UPF) receiving a transmission from a first user equipment (UE) in the LAN, the transmission intended for a second UE in the LAN.
[0140]
[0141] Step s1204 includes forwarding the transmission to the second UE, the UPF being associated with both the first UE and the second UE, and the receiving and forwarding includes applying ingress and egress operations (e.g., QoS, charging, and counting) to both the first UE and the second UE for the transmission.
[0141]
[0142] Steps s1202 and S1204 are performed by the UPF in some embodiments.
[0142]
[0143] 13 is a flow diagram illustrating a process 1300 for supporting a LAN (e.g., a 5G LAN). The process 1300 may begin at step s1302.
[0143]
[0144] Step s1302 includes a first user plane function (UPF) receiving a transmission from a first user equipment (UE) in the LAN, the transmission intended for a second UE in the LAN.
[0144]
[0145] Step s1304 includes forwarding the transmission to the second UE, where the forwarding includes forwarding the transmission via a tunnel connection between the first UPF and a second UPF in accordance with a packet detection rule (PDR) that specifies a forwarding action rule (FAR) that specifies the second UPF (e.g., the FAR includes an address assigned to the second UPF).
[0145]
[0146] Steps s1302 and S1304 are performed by the UPF in some embodiments.
[0146]
[0147] FIG. 14 illustrates a node and signal flow diagram of a system 1400 according to some embodiments. In this example, when the SMF gets a query for a destination UE (UE2 in this example), it installs a PDR (to identify UE-UE traffic toward UE2) and a FAR (to forward the traffic to UPF2) in both UPF1 and UPF3. In this way, the forwarding table in UPF is completed. According to an embodiment, when UE2 moves to UPF3 and UE1 wants to communicate to UE2, such UE-to-UE traffic is sent to UPF2, but UPF2 does not have an entry to forward traffic to UE2 because the local switch part for UE2 is removed when UE2 moves. Therefore, UPF2 requests SMF to install PDR / FAR in UPF1, and the old entry for UE2 in UPF1 is removed. In some examples, when UE2 is directly connected to UPF3, the old PDR / FAR to forward traffic toward UE2 via UPF2 is removed. In flow (1) of FIG. 3, UPF1 reports to the SMF that packets destined for UE2 are not routable (according to the alternatives described herein). In flow (2) of FIG. 10, a PDR (to identify traffic destined for UE2) and a FAR (toward UPF2) are installed in UPF1. In flow (3) of FIG. 14, a PDR (to identify traffic destined for UE2) and a FAR (toward UPF2) are installed in UPF3 so that any UE behind UPF3 can communicate with UE2 in the future. In this example, a tunnel is provided between each of UPF1 to UPF3.
[0147]
[0148] According to some embodiments, a new PDR / FAR is provided each time a new UE in the group / LAN is identified, which may occur, for example, when establishing a new N3 or N4 session for such a UE.
[0148]
[0149] According to some embodiments, there is provided an apparatus adapted to perform any of the steps of Figures 4-13.
[0149]
[0150] According to some embodiments there is provided a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to perform a procedure according to any of Figures 4 to 13. According to some embodiments there is provided a carrier having the computer program stored thereon, the carrier being any of an electronic signal, an optical signal, a radio signal or a computer readable storage medium.
[0150]
[0151] According to some embodiments, there is provided an apparatus for supporting a local area network (LAN) (e.g., a 5G LAN), the apparatus comprising a processor and a memory, the memory including instructions executable by the processor, whereby the apparatus is operable to perform any of the steps of Figures 4-13.
[0151]
[0152] According to some embodiments there is provided a computer program having computer program code stored on a permanent computer readable medium which, when executed on a network node, causes the network node to perform any of the steps of Figures 4 to 13.
[0152]
[0153] FIG. 15 is a block diagram of a device 1500 that may implement a UPF and / or SMF, according to some embodiments. As shown in FIG. 15, the device 1500 may include a processing circuit (PC) 1502 that may include one or more processors (P) (e.g., a general-purpose microprocessor and / or one or more other processors, such as an application specific integrated circuit (ASIC), field programmable gate array (FPGA), etc.) that may be located in a single housing or in a single data center, or may be geographically distributed; a network interface 1548 having a transmitter (Tx) 1545 and a receiver (Rx) 1547 to enable the device 1500 to transmit and receive data to and from other nodes connected to the network 150 (e.g., an Internet Protocol (IP) network); and a local storage device (a.k.a., a "data storage system") 1508 that may include one or more non-volatile storage devices and / or one or more volatile storage devices. In an embodiment in which the PC 1502 includes a programmable processor, a computer program product (CPP) 1541 may be provided. The CPP 1541 includes a computer readable medium (CRM) 1542 that stores a computer program (CP) 1543 having computer readable instructions (CRI) 1544. The CRM 1542 may be a permanent computer readable medium, such as, for example, a magnetic medium (e.g., a hard disk), an optical medium, a memory device (e.g., a random access memory, a flash memory), or the like. In some embodiments, the CRI 1544 of the computer program 1543, when executed by the PC 1502, is configured such that the CRI causes the device 1500 to perform the steps described herein (e.g., steps described herein with reference to any of the flowcharts). In other embodiments, the device 1500 may be configured to perform the steps described herein without the need for code. That is, for example, the PC 1502 may simply be comprised of one or more ASICs. Thus, features of the embodiments described herein may be implemented in hardware and / or software.
[0153]
[0154] Embodiment A1. 1. A method for supporting communication between UEs camped on a local area network (LAN) (e.g., a 5G LAN), the method being performed by a user plane function (UPF), the method comprising: receiving a transmission including a protocol data unit (PDU) sent by a first user equipment (UE) (e.g., a GTP-U PDU sent by an access network node or a PDU sent over an Nx interface by another UPF), where the PDU includes at least a destination address of a second UE; using information included in the transmission to find a first Packet Detection Rule (PDR) that matches information included in the transmission (e.g., a source address and a destination address of the PDU), where the first PDR identifies a first Forwarding Action Rule (FAR), where the first FAR includes an indication (e.g., a destination interface set to "5G-LAN-internal") that indicates that the PDU requires further ingress processing (i.e., another PDR matching process is required for the PDU); Implementing the first FAR (e.g., sending the PDU to a routing engine of the UPF using a network instance identifier included in the FAR and a 5G LAN internal interface, and allowing the routing engine to perform another PDR matching process to find a second PDR for the PDU); finding a second PDR for the PDU (e.g., the second PDR is found after identifying a second N4 session for the PDU and by matching the PDU with a packet detection information (PDI) included in the second PDR), where the second PDR identifies a second FAR; and enforcing the second FAR, wherein enforcing the second FAR includes forwarding the PDU to the second UE using information included in the second FAR.
[0154] A1.1. In the method of embodiment A1, the step of finding the first PDR using information included in the transmission includes identifying a first N4 session (e.g., an N4 session corresponding to a 5G LAN group, or an N4 session corresponding to the PDU transmitted by the first UE) using information included in the transmission (e.g., a local TEID previously assigned to the PDU session of the first UE (to receive GTP-U from an access network), or a local TEID previously assigned to an N4 session created for a specific 5G LAN group (to receive GTP-U from a first UPF)) before finding the first PDR; The method, wherein the first PDR is associated with the identified N4 session.
[0155] A1.2. The method of any of the previous embodiments. The transmission includes an outer header (e.g., a GTP-U header) to which the PDU is attached; and The method of claim 1, wherein the first PDR includes instructions to remove the outer header.
[0156] A1.3. The method of any of the previous embodiments. The method, wherein the first PDR includes a first PDI to enable the first UPF to identify the PDU as relating to 5G LAN group traffic (e.g., the PDI specifies source and destination address ranges, or any other valid bits within the PDU that can be used to identify an application used for the communication within a given 5G LAN group).
[0157] A2. The method of any of the previous embodiments. The first FAR includes a destination interface information element (IE) that stores an interface value (e.g., a value greater than 4 and less than 16); and The indication that the PDU requires further ingress processing is the interface value of the Destination Interface IE.
[0158] A3. The method of embodiment A2, wherein the first FAR further includes a network instance IE that stores a network instance value that identifies a particular 5G LAN group.
[0159] A3.1: The method of embodiment A1, The method, wherein the second PDR includes a second PDI for matching the PDU coming from a source interface (e.g., inside a 5G LAN) with a network domain (e.g., an IP domain) specific to traffic of the 5G LAN group identified by a network instance.
[0160] A3.1.1: The method of embodiment A3.1, The second PDI includes at least a packet flow description in which the destination IP address is set to an IP address belonging to the second UE.
[0161] A3.2: The method of embodiment A1, The method, wherein the second N4 session is an N4 session created for a PDU session of the second UE, or the second N4 session is an N4 session created for a specific 5G LAN group shared by all UEs associated with the same 5G LAN group, enables communication for UEs when the UEs are served by different UPFs, and forwards the packets directly to a packet data network via N6.
[0162] A4. The method of any of the previous embodiments, wherein the first UPF serves the second UE and forwarding the PDU to the second UE includes the UPF forwarding the PDU to the access network node (e.g., a 5G-AN node) using a tunnel (e.g., an N3 GTP-U tunnel) established between the first UPF and an access network node.
[0163] A5. The method of embodiment A4, wherein the second FAR includes a destination interface IE that includes an interface value set to access (i.e., set to 0).
[0164] A6. The method of any one of the preceding embodiments, forwarding the PDU to the second UE; The first UPF forwards the PDU to a second UPF (which may be a UPF serving the second UE or a UPF between the first UPF and a UPF serving the second UE) using a tunnel (e.g., an N9 GTP-U tunnel) established between the first UPF and the second UPF; or The method comprises the first UPF forwarding the PDU to a packet data network (eg, using an N6 interface).
[0165] A7. The method of embodiment A6, wherein the second FAR includes a destination interface IE that stores an interface value (e.g., "5G LAN Nx") indicating that the UPF should forward the PDU to the second UPF using a tunnel established between the first UPF and the second UPF.
[0166] A7.1 The method of embodiment A6, wherein the second FAR includes a destination interface IE that stores an interface value (e.g., core) indicating that the UPF should forward the PDU to a packet data network through an N6 interface.
[0167] A7.2 The method of embodiment A7, wherein the second FAR further includes a Network Instance IE that identifies a network domain (e.g., IP domain) specific to 5G LAN group traffic.
[0168] A8. The method of any one of embodiments A3, comprising: the second PDR includes a Source Interface IE that stores an interface value that is set to the same value as the interface value of the Destination Interface IE included in the first FAR; and the second PDR includes a network instance IE that stores a network instance value that is set to the same value as the network instance value of the network instance IE included in the first FAR.
[0169] A9. 20. The method of any one of the preceding embodiments, comprising: The first PDR includes a usage reporting rule (URR) identifier that identifies a first URR; The second PDR includes a URR identifier that identifies a second URR; and The method further comprises: the first UPF applying the first URR with respect to the PDU; the first UPF applying the second URR with respect to the PDU.
[0170] A10. The method of embodiment A9, comprising: the first URR specifying a method for measuring network resource usage; 4. The method of claim 3, wherein applying the first URR with respect to the PDU includes measuring the network resource usage with respect to the PDU.
[0171] B1. 1. A method for supporting communication between UEs camped on a local area network (LAN) (e.g., a 5G LAN), the method being performed by a user plane function (UPF), the method comprising: receiving a transmission including a protocol data unit (PDU) transmitted by a first user equipment (UE) (e.g., a GTP-U PDU transmitted by an access network node or a PDU transmitted over an Nx interface by another UPF), where the PDU includes at least a destination address of a second UE; using information included in the transmission to find a first Packet Detection Rule (PDR) that matches information included in the transmission (e.g., a source address and a destination address of the PDU), where the first PDR identifies a first Forwarding Action Rule (FAR), where the first FAR includes an indication (e.g., a destination interface set to "5G-LAN-internal") that indicates that the PDU requires further ingress processing (i.e., another PDR query process is required for the PDU); Obtaining information contained in the first FAR (e.g., reading a value of a destination interface IE contained in the FAR); identifying an N4 session after obtaining information contained in the first FAR; After identifying the N4 session, finding a default PDR associated with the N4 session, the default PDR identifying a default FAR and / or a default URR; The default FAR is configured to cause the UPF to transmit the PDU to a session management function (SMF); The method, wherein the default URR is configured to cause the UPF to send a PFCP session report request message including at least a portion of the PDU (e.g., the destination IP address included in the IP header of the PDU) to the SMF.
[0172] B2. The method of embodiment B1, further comprising: transmitting the PDU to the SMF; The method includes, after transmitting the PDU to the SMF, receiving a second PDR associated with the second N4 session and receiving the second FAR from the SMF, the second PDR including a FAR identifier that identifies the second FAR.
[0173] B3. The method of embodiment B1, further comprising: sending the PFCP session report request message to the SMF; The method includes, after sending the PFCP session report request message to the SMF, receiving a second PDR related to the second N4 session and receiving a second FAR from the SMF, the second PDR including a FAR identifier that identifies the second FAR.
[0174] C1. 1. A method for supporting communication between UEs camped on a local area network (LAN) (e.g., a 5G LAN) in a 5G core network, the method being performed by a session management function (SMF), the method comprising: receiving a transmission sent by a first user plane function (UPF) as a result of the first UPF determining that a PDU is not routable, where the PDU includes a source address field that stores an address of a first UE and a destination address field that stores an address of a second UE, the transmission including 1) a PDU, or 2) a PFCP Session Report Request message that includes the address of the second UE; Identifying a UPF currently serving the second UE; and After identifying a UPF currently serving the second UE, provisioning a PDR to the first UPF that enables the first UPF to route a PDU destined for the second UE toward the second UE.
[0175] C1.1 The method of embodiment C1, wherein the PDR is in an N4 session created specifically for a 5G LAN group to which the first and second UEs belong.
[0176] C2. The method of embodiment C1, further comprising: The method includes provisioning a second PDR to the second UPF to enable the second UPF to route a PDU addressed to the second UE and intended for the 5G LAN group toward the second UE.
[0177] C2.1. The method of embodiment C2, comprising: The method, wherein the second PDR includes instructions to remove an outer header of a PDU received from a unique network domain (e.g., an IP domain) identified by a source interface 5G LAN Nx and a network instance, and the second PDR is associated with a FAR.
[0178] C2.2. The method of embodiment C2.1, comprising: the FAR includes a destination interface IE including an interface value (e.g., "5G LAN Internal"), and a network instance is set to a value specific to a 5G LAN group indicating that the second UPF enforces the FAR, e.g., by sending the PDU to a routing engine of the UPF using a network instance identifier included in the FAR and a 5G LAN internal interface, thereby enabling the routing engine to perform another PDR matching process to find another PDR for a second UE N4 session for the PDU.
[0179] C3. The method of embodiment C1, comprising: The SMF generates the PDR based on the UPF currently serving the second UE (e.g., if a second UPF is serving the second UE, the PDR would include, for example, a FAR identifier that identifies a FAR with a destination interface IE set to 5G LAN Nx and a network instance that identifies a network domain (e.g., IP domain) specific to 5G LAN group traffic).
[0180] D1. A method performed by a Session Management Function (SMF) of a 5G core network, the method comprising: generating a first packet detection rule (PDR) associated with a first N4 session associated with a first UE or associated with a 5G LAN group, where the first PDR includes a forwarding action rule (FAR) identifier for identifying a first FAR; generating the first FAR, where the first FAR includes an indication (e.g., a destination interface set to “5G-LAN-internal”) that a PDU matching the first PDR requires further ingress processing (i.e., another PDR matching process is required for the PDU); providing the first PDR and the first FAR to a first user plane function (UPF) (e.g., a UPF selected to serve the first UE).
[0181] D2. The method of embodiment D1, wherein the SMF provides the first PDR to the first UPF by sending a session request (e.g., a session creation request or a session modification request) including the first PDR to the first UPF.
[0182] D3. The method of embodiment D1 or D2, further comprising: generating a second PDR associated with a second N4 session, where the second PDR includes a FAR identifier for identifying a second FAR; generating the second FAR; providing the second PDR and the second FAR to the first UPF; The method wherein the destination interface IE of the second FAR is set to core, access, or 5G LAN Nx (e.g., a value greater than 4 and less than 16).
[0183] D3.1 The method of embodiment D2, wherein the Network Instance IE of the second FAR is set to a value that identifies a network domain (e.g., IP domain) specific to 5G LAN group traffic.
[0184] D4. The method of embodiment D3, wherein the second PDR is associated with an N4 session created for a particular 5G LAN group, and a destination interface IE of the second FAR is set to 5G LAN Nx.
[0185] D5. The method of embodiment D3, wherein the second PDR is associated with an N4 session associated with a second UE, and a destination interface IE of the second FAR is set to access.
[0186] E1. A computer program comprising instructions which, when executed on at least one processor, cause said at least one processor to perform the method of any one of the preceding embodiments.
[0187] E2. A carrier comprising the computer program of embodiment E1, the carrier being any one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.
[0188] F1. An apparatus configured to perform the steps of any of the previous embodiments (e.g., an apparatus implementing the UPF or SMF).
[0189] G1. A UPF configured to perform the steps of any of the preceding embodiments.
[0190] H1. 2. An SMF configured to perform the steps of any of the preceding embodiments.
[0191]
[0155] Additional Embodiments A1. 1. A method for supporting a local area network (LAN) (e.g., a 5G LAN), the method comprising: generating a first packet detection rule (PDR) associated with a first user equipment (UE), where the first PDR includes a forwarding action rule (FAR) identifier for identifying a first FAR; generating the first FAR, where the first FAR includes: i) an indication (e.g., “internal”, “5G-LAN”) indicating that at least a second PDR (e.g., an ingress PDR) should be applied to packets that match the first PDR (e.g., packets that match a packet detection information (PDI) included in the PDR); and / or ii) an identifier (e.g., an N4 session identifier) used to identify a set of one or more PDRs; providing the first PDR and the first FAR to a first user plane function (UPF) selected to serve the first UE; The set of one or more PDRs is associated with i) a second UE, or ii) a tunnel between the first UPF and a second UPF; and / or The method, wherein the second PDR is associated with i) a second UE, or ii) a tunnel between the first UPF and a second UPF.
[0192] A2. The method of embodiment A1, comprising: the first FAR includes the identifier; the identifier included in the first FAR is an N4 session identifier that identifies an N4 session associated with the second UE; Each PDR in the set of one or more PDRs includes the N4 session identifier.
[0193] A3. The method of embodiment A1 or A2, wherein the method is performed by a Session Management Function (SMF) that provides session management functionality for both the first UE and the second UE.
[0194] A4. The method of embodiment A3, wherein the SMF generates the first PDR and the first FAR after the second UE connects to the LAN.
[0195] A5. The method of embodiment A4, wherein the SMF provides the first PDR to the first UPF by sending a session modification request including the first PDR to the first UPF.
[0196] A6. The method of any one of embodiments A3 to A5, further comprising: The SMF receives a transmission from the first UPF including an identifier (e.g., an IP address) associated with the second UE; and determining a UPF currently serving the second UE; The SMF generates the first FAR based on a UPF currently serving the second UE.
[0197] A7. The method of embodiment A6, wherein the UPF serving the second UE is the second UPF, and the set of PDRs and / or the second PDR are associated with the tunnel between the first UPF and the second UPF.
[0198] A8. The method of embodiment A6, wherein the UPF serving the second UE is the first UPF, and the set of PDRs and / or the second PDR are associated with an N4 session identifier associated with the second UE.
[0199] A9. The method of any one of embodiments A6 to A8, wherein the transmission from the first UPF includes an uplink (UL) packet transmitted by the first UE, the UL packet including an IP address assigned to the second UE.
[0200] A10. The method of any one of embodiments A6 to A8, wherein the transmission from the first UPF includes a session report request message.
[0201] A11. The method of any one of embodiments A1 to A10, comprising: The FAR includes a destination interface attribute; The method, wherein the indication is a destination interface value of the destination interface attribute (e.g., “internal” and / or “5G-LAN”).
[0202] A12. The method of any one of embodiments A1 to A10, comprising: the second PDR includes an indicator that the second PDR applies to locally switched traffic (e.g., applies to packets having a source on the LAN and having a destination on the LAN), the method further including providing the second PDR to the first UPF; or The method, wherein the set of PDRs includes a second PDR that includes an indicator indicating that the second PDR applies to locally switched traffic (e.g., applies to packets having a source on the LAN and having a destination on the LAN), the method further including providing the second PDR to the first UPF.
[0203] A13. The method according to embodiment A12, comprising the steps of: The second PDR has a source interface attribute; The method of claim 1, wherein the indicator that the second PDR applies to locally switched traffic is a source interface attribute value of the source interface attribute of the second PDR.
[0204] A14. The method of any one of embodiments A1 to A13, wherein the first FAR comprises: i) the indication that at least a second PDR should be applied to packets that match the first PDR; and ii) the identifier (e.g., an N4 session identifier) used to identify a set of one or more PDRs, the set of PDRs including the second PDR.
[0205] B1. 1. A method for supporting a local area network (LAN) (e.g., a 5G LAN), the method comprising: A first user plane function (UPF) receiving a transmission including a protocol data unit (PDU) transmitted by a first user equipment (UE), where the PDU includes a destination address of a second UE (e.g., a GTP-U PDU transmitted by an access network node); the first user plane function using information included in the transmission (e.g., a destination address of the PDU) to determine a first rule (e.g., a Packet Detection Rule (PDR)) for the PDU, where the first rule specifies a first Forwarding Action Rule (FAR); After identifying the first rule, the first UPF searches the first FAR; the first UPF using information included in the first FAR to determine a second rule for the PDU, where the second rule specifies a second FAR; After identifying the second rule, the first UPF searches for the second FAR; and the first UPF forwarding the PDU to the second UE using information contained in the second FAR.
[0206] B2. The method of embodiment B1, wherein the first UPF serves the second UE and forwarding the PDU to the second UE includes the UPF forwarding the PDU to the access network node (e.g., a 5G-AN node) using a tunnel (e.g., an N3 GTP-U tunnel) established between the first UPF and the access network node.
[0207] B3. The method of embodiment B1, wherein the second UPF serving the second UE and forwarding the PDU to the second UE includes the first UPF forwarding the PDU to the second UPF using a tunnel (e.g., an N9 GTP-U tunnel) established between the first UPF and the second UPF.
[0208] B4. The method of any one of embodiments B1 to B3, comprising: the first rule includes a Usage Reporting Rule (URR) identifier that identifies a first URR; the second rule includes a usage reporting rule (URR) identifier that identifies a second URR; The method further comprises: the first UPF applying the first URR with respect to the PDU; the first UPF applying the second URR with respect to the PDU.
[0209] B5. The method of embodiment B4, comprising: The first URR specifies a method for measuring network resource usage; 4. The method of claim 3, wherein applying the first URR with respect to the PDU includes measuring the network resource usage with respect to the PDU.
[0210] B6. The method of any one of embodiments B1 to B5, further comprising: The first UPF receives a transmission sent by a UE, where the transmission includes a PDU that stores a destination address of a third UE; The first UPF verifies that the PDU matches a default PDR that includes a FAR identifier that identifies a third FAR; and The first UPF searches for the third FAR, where the third FAR instructs the first UPF to forward the PDU to a session management function; and the first UPF forwarding the PDU to the SMF according to an instruction of the third FAR.
[0211] B7. The method of any one of embodiments B1 to B5, further comprising: The first UPF receives a transmission sent by a UE, where the transmission includes a PDU that stores a destination address of a third UE; The first UPF verifies that the PDU matches a default PDR that includes a rule identifier that identifies a universal request rule; The first UPF retrieves the URR, where the URR instructs the first UPF to send a report (e.g., a report including a destination address of the third UE) to an SMF; The first UPF sends the report to the SMF according to instructions from the URR.
[0212] C1. 1. A method for supporting a local area network (LAN) (e.g., a 5G LAN), the method comprising: generating a packet detection rule (PDR) that specifies a forwarding action rule (FAR), where the PDR and / or the FAR define how to route traffic from a first user equipment (UE) in the LAN to a second UE in the LAN; providing the PDR to a User Plane Function (UPF), the UPF being associated with the first UE and the second UE; The method, wherein the PDR and / or FAR enable the UPF to apply ingress and egress operations (e.g., QoS, charging, and counting) to both the first and second UEs.
[0213] C2. The method of embodiment C1, wherein the PDR and / or FAR specify how to route the traffic from the first UE to the second UE without using an external data network (DN) (e.g., via N6).
[0214] D1. 1. A method for supporting a local area network (LAN) (e.g., a 5G LAN), the method comprising: generating a first packet detection rule (PDR) that specifies a forwarding action rule (FAR), where the PDR and / or FAR specifies how to route traffic (e.g., one or more packets) from a first user equipment (UE) of the LAN to a second UE of the LAN; providing the PDR to a first User Plane Function (UPF), the UPF being associated with the first UE; The FAR includes one or more instructions for the first UPF to route the traffic to a second UPF via a tunnel connection between the first and second UPFs (e.g., one or more instructions for causing the first UPF to add a particular header to a packet); The method, wherein the second UPF is associated with the second UE.
[0215] D2. The method of embodiment D2, wherein the PDR and / or FAR specify how to route the traffic from the first UE to the second UE without using an external data network (DN) (e.g., via N6).
[0216] E1. 1. A method for supporting a local area network (LAN) (e.g., a 5G LAN), the method comprising: a first user plane function (UPF) receiving a transmission from a first user equipment (UE) in the LAN, the transmission being intended for a second UE in the LAN; and forwarding the transmission to the second UE; the UPF is associated with both the first UE and the second UE; The method, wherein the receiving and forwarding includes applying ingress and egress behaviors (e.g., QoS, charging, and counting) to both the first UE and the second UE for the transmission.
[0217] F1. 1. A method for supporting a local area network (LAN) (e.g., a 5G LAN), the method comprising: a first user plane function (UPF) receiving a transmission from a first user equipment (UE) in the LAN, the transmission being intended for a second UE in the LAN; and forwarding the transmission to the second UE; The method, wherein the forwarding includes sending the transmission via a tunnel connection between the first UPF and a second UPF in accordance with a packet detection rule (PDR) that specifies a forwarding action rule (FAR) that specifies the second UPF.
[0218] G1. An apparatus adapted to carry out the steps of any of embodiments A-F.
[0219] G2. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to perform the method of any one of embodiments A-F.
[0220] G3. A carrier storing the computer program of the previous embodiment, said carrier being any one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.
[0221] G4. An apparatus for supporting a local area network (LAN) (e.g., a 5G LAN), having a processor and a memory, the memory storing instructions executable by the processor, whereby the apparatus is operable to perform the steps of any of embodiments A-F.
[0222] G5. A computer program comprising computer program code stored on a permanent computer-readable medium, the computer program causing the network node to perform the steps of any one of embodiments A to F when executed on the network node.
[0223]
[0156] While various embodiments are described herein (including the attached appendix containing proposals to amend the 3GPP standard), it should be understood that they are presented by way of example, and not by way of limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the exemplary embodiments described above. Moreover, all possible combinations of the elements described above are encompassed by the present disclosure unless otherwise indicated herein or clearly contradicted by context.
[0224]
[0157] Moreover, while the procedures described above and illustrated in the figures are depicted as a series of steps, this is for illustrative purposes only, and it is therefore contemplated that some steps may be added, some steps may be omitted, the order of the steps may be rearranged, and some steps may be performed in parallel.
[0225]
[0158] As explained in paragraph 0016, for example, a network function may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, e.g., a cloud infrastructure. Also, as explained in paragraph 0026, for example, a virtual network capable of supporting 5G LAN type services may be referred to as a 5G LAN-Virtual Network, or, for simplicity, simply as a 5G VN. (The abbreviation VN is used, for example, in paragraph 0007 in the Background section, 6.29.1.3 PDU Session Management 5G LAN Type Services.)
[0226]
[0159] Thus, according to example embodiments, when a 5G LAN group is referenced herein, what is considered may be a 5G VN group, and / or when a 5G LAN internal (switching) is referenced herein, what is considered may be 5G VN internal (switching).
[0227]
[0160] In general, for evolving network architectures, interfaces that have not yet been assigned a number are denoted as x. For 5G system architectures, interfaces are denoted as N along with a number. That is, an interface Nx referred to herein simply means an interface in the 5G system architecture that has not yet been assigned a specific number.
[0228]
[0161] According to an exemplary embodiment, the Nx interface is an N19 interface. Thus, according to an embodiment, the Nx interface may be an N19 interface and / or Nx forwarding allows for N19 forwarding.
[0229]
[0162] In light of the above, according to an embodiment, the 5G LAN Nx (interface) may be a 5G VN N19 (interface).
[0230] appendix I. Introduction This appendix explores solutions for how the SMF controls the various traffic forwarding options used in 5G-LAN and suggests future directions. SA2#129-BIS agreed to support various options for routing UP traffic within the 5G-LAN group. There are the following types of traffic routing policies for 5GLAN communication: (1) N6-based: This means that all UL / DL traffic of 5G LAN communication is routed to and from the DN. (2) Nx-based: This means that all UL / DL traffic of 5G LAN communication is routed between the PSA UPFs of different PDU sessions. (3) Local Switch: If a single PAS UPF is common to different sessions, traffic is routed locally by that single UPF. The SMF generates PDU forwarding rules and provides them to the UPF. Analyze the impact on N4 and UPF to support the above mentioned options. The first approach (N6-based) is supported in the rel-15 baseline, so no new requirements are required. The second approach (Nx-based) and the third approach (local switch) may or may not require an N4 extension depending on the requirements, which we will analyze in more detail below.
[0231] II. Discussion A.Local Switch in UPF Local switch forwarding in UPF requires that UL / DL user data traffic is switched (exchanged) within UPF between a PDU session controlled by N4 session (for a UE as a 5G-LAN group member) and another PDU session (for another UE as a member of the same 5G-LAN group) without being transmitted on an external interface (N6, N9, etc.). In Rel-15, there is implicit support for this, but only for Ethernet PDU sessions, and not explicit as described in TS 23.501 clause 5.8.2.5.
[0232] The UPF local policy associated with a network instance may prevent local traffic switching between PDU sessions within the UPF for unicast traffic only or for any traffic. If the UPF policy does not allow local traffic switching for any traffic (i.e. broadcast / multicast traffic), mechanisms such as ARP / ND proxy or local multicast group handling are required to ensure that higher layer protocols can run on top of the Ethernet PDU sessions.
[0233] For UPF to do local switching, UPF would need to receive UL packets of one PDU session, do the relevant processing (PDR, QER, URR, FAR), and then send them as DL to another PDU session after doing the relevant processing (PDR, QER, URR, FAR) for that PDU session. The question is how to connect the egress of UL processing to the ingress of DL processing. For example, is it possible to connect the FAR of UL traffic to the PDR of DL traffic?
[0234] It might be possible to leave the "local switch" to the SMF / UPF implementation based on local configuration to perform the local switch. The SMF could, for example, give the FAR a specific network instance value that the UPF would interpret as traffic should not be sent to an external interface and should be fed back again to internal processing (PDR classification). The same network instance value could then be used in one or more PDRs for UEs belonging to the same 5 G-LAN group. However, typically the network instance would indicate an IP domain outside the UPF and would be connected to either the source or destination interface. This option does not have any new N4 requirements, but it might limit SMF-UPF interoperability. Another issue is the lack of suitable values for the "destination interface" and "source interface" parameters of the FAR and PDR. Currently, these parameters can take the following values, indicating that in all cases the packet is sent to or received from an external interface:
[0235] Table 1: Current values of the "Destination Interface" and "Source Interface" parameters in the FAR and PDR (from TS 29.244) [Table 1]
[0236] Observation 1: Leaving the "local switch" to the SMF / UPF configuration with the "network instance" reduces interoperability and creates problems with the "destination interface" and "source interface" fields.
[0237] It is therefore preferable to standardize new values for "source interface" and "destination interface" to represent interfaces within the UPF. It is easy to add a new value (e.g. "5G LAN inside") and tell UPF to route it via the local switch.
[0238] The network instance value may also be used to separate traffic between 5G-LAN groups so that traffic from one 5G-LAN group is not mixed with traffic associated with another 5G-LAN group or with non-5G-LAN groups. The network instance value may be set, for example, to a value that represents a 5G-LAN group.
[0239] Proposal 1: Define a new value ("5G LAN inside") for "destination interface" and "source interface" that indicates the local switch. By separating traffic by this and the network instance number for each 5G LAN group, we provide a consistent and interoperable solution for local switches.
[0240] The diagram and simple "call flow" in Figure 16 shows the processing in the UPF.
[0241] As specified in TS 29.244 clause 5.2.1, in the packet forwarding model shown in Figure 16, an incoming packet is matched in the UPF in two steps: first, it finds a PFCP session, and then it matches it against one of the PDRs in that PFCP session.
[0242] So, to support the local switch scenario, an example is shown in FIG. In this example, assume that UE1 and UE2 belong to 5G LAN group 1 and have PSAs in the same UPF.
[0243] Figure 1. Local switch in UPF 1. The UPF receives an incoming packet intended for UE2 from the RAN (source interface = "access") and identifies UE1's N4 session based on the local TEID previously assigned by the UPF. 2. The UPF finds a PDR in that N4 session that matches the packet, which identifies that the packet is intended for UE-to-UE communication in 5G LAN group 1, e.g., destined for UE 2 served by the same UPF.
[0244] NOTE 1: In this step, the packet is identified for UE-to-UE communication, for example for UE 2. The purpose is to send the packet back to the ingress (after removing the outer header) with destination interface set to 5G LAN internal and network instance set to 5G LAN Group 1. This ensures that the packet matches the PDR either provisioned for UE 2's N4 session or provisioned for 5G LAN Group 1's N4 session.
[0245] 3. The FAR associated with the matching PDR contains destination interface = "5G LAN internal" and network instance "5G LAN Group 1", so the packet after the outer GTP-U header is removed is sent back to the ingress, e.g., the routing engine, so that the UPF again identifies the N4 session according to the packet forwarding model.
[0246] 4. The UPF identifies the N4 session for UE2 by matching the PDR specified in the N4 session based on the destination address of UE2 and the “source interface” set to “inside 5G-LAN”.
[0247] NOTE 2: Only one PDR is provisioned for matching packets intended for UE2 from the 5G LAN group, i.e. from source interface 5G LAN inside, network instance 5G LAN group 1.
[0248] 5. The UPF processes the associated FAR for that PDR, adds an outer header to the packet set to the remote TEID assigned to UE2's PDU session, and sets the destination interface to "access" so that UE3 can receive the packet.
[0249] B.Nx-based forwarding In Nx-based forwarding, UL / DL data traffic needs to be switched between a PDU session controlled by an N4 session provided by a UPF (for a UE that is a member of a 5G-LAN group) and another PDU session controlled by another N4 session provided by another UPF (for another UE that is a member of the same 5G-LAN group). The UL / DL data traffic is carried between the two UPFs in a shared tunnel (Nx) per 5G LAN group.
[0250] One important question here is whether a shared tunnel needs its own N4 session. If there is no need to associate a shared tunnel with a specific QoS, usage reporting, etc., then the SMF only needs to provide a PDR and FAR related to the N4 session for each PDU session. For example, in the UL, the N4 session may have a PDR with a specific destination MAC address of the other 5G-LAN group member, and a FAR that instructs the UPF to send packets matching the TEID of the shared tunnel. The packets will be enforced according to the QER, URR, etc. of the PDU session.
[0251] However, it becomes more complicated if there are QoS, usage reporting, etc. requirements associated with this shared tunnel, such as forcing all packets on the tunnel to a certain bit rate or counting the volume on the shared tunnel. Furthermore, a problem with this approach is that each N4 session for the UE needs to be updated to include the destination addresses of other UEs that belong to that group but have other PSA UPFs. This method may not be scalable if the number of UEs in the group is large.
[0252] Observation 2: Simply using an N4 session for each UE to include a FAR to forward packets to Nx does not allow the Nx tunnel to be rate-limited (if necessary) and is not very scalable in terms of the number of UEs in the 5G-LAN group, see below (explanation).
[0253] Note: If there is no N4 session for 5G LAN group 1, the CP function needs to provision a PDR in the N4 session for UE1 to forward packets towards UPF2. This applies to all UEs in UPF1 that want to communicate with UE3 in UPF2. This is not scalable because if UE3 moves from UPF2 to UPF3, many PDRs need to be updated (huge amount of signaling), while UEs in UPF1 may not communicate with UE3 at all. Instead, one PDR needs to be updated for the N4 session for 5G LAN group 1. Similarly for the receiving side, in the N4 session for UE3, the CP function needs to provision a PDR to query packets received from Nx local TEID. This applies to the N4 sessions of all UEs that may receive packets from Nx.
[0254] A potential solution would be to create one or more shared tunnel N4 sessions (which we will call Nx sessions for the sake of the solution) per 5G LAN group, allowing a specific QER and / or URR to be associated with the shared tunnel, allowing different QoS policies to be applied depending on the 5G LAN group.
[0255] Using an N4 session for a shared tunnel also allows a single PDR to be defined to match incoming packets with different source UE IP addresses to UEs served by the receiving UPF, and is therefore more scalable than using a separate N4 session per PDU session. However, this alternative requires that the SMF can instruct the UPF to forward traffic between two N4 sessions (one for the PDU session and one for the Nx session) within one UPF, which is essentially the same as the "local switch" mentioned above. Therefore, the same mechanics apply.
[0256] Proposal 2: For Nx-based forwarding, SMF creates a group-level N4 session (for Nx tunnels) and maps uplink traffic from PDU sessions to the group-level N4 session in the same way as "local switch". However, there is room to reconsider whether the available values of "destination interface" and "source interface" are appropriate to send packets over Nx tunnels. Nx tunnels do not seem to correspond to any of the values in Table 1 above. Therefore, a new value (e.g., "5G LAN Nx") would be appropriate.
[0257] Proposal 3: Define a new value for "Destination Interface" and "Source Interface" ("5G LAN Nx") to indicate Nx-based forwarding.
[0258] See Figure 18 for Nx-based forwarding in UPF. 1. UPF1 receives an incoming packet from the RAN (destination interface = "access") and identifies UE1's N4 session based on the local TEID previously assigned by UPF.
[0259] 2. UPF1 finds a PDR in its N4 session that matches the packet, which identifies that the packet is intended for UE-to-UE communication in 5G LAN group 1, e.g., destined for UE 3 served by another UPF 2.
[0260] NOTE 1: In this step, the packet is identified for UE-to-UE communication, for example for UE 2. The purpose is to send the packet back to the ingress (after removing the outer header) with destination interface set to 5G LAN internal and network instance set to 5G LAN Group 1. This ensures that the packet matches the PDR either provisioned for UE 2's N4 session or provisioned for 5G LAN Group 1's N4 session.
[0261] 3. UPF1 processes the FAR associated with the matching PDR and forwards the packet with the outer GTP-U header removed to the ingress (e.g., routing engine) with the destination interface set to "5G LAN internal" and the network instance set to "5G LAN group 1". This causes UPF to re-identify the N4 session according to the packet forwarding model.
[0262] 4. UPF1 identifies an N4 session that matches the PDR based on the destination address of UE3 (source interface = "5G-LAN inside") This shows a group-level N4 session created in this UPF to match traffic entering and leaving 5G LAN group 1.
[0263] 5. UPF1 processes the FAR associated with that PDR and the packet is added with an outer header set to the remote TEID assigned by UPF2 to receive 5G LAN group 1 traffic and a destination interface set to “5G-LAN Nx”.
[0264] 6. UPF2 receives the packet with the local TEID and identifies the N4 session based on the tunnel header (Nx Tunnel Header). This N4 session is created in this UPF to match traffic to and from 5G LAN group 1.
[0265] 7. UPF2 processes the FAR associated with that PDR and forwards the packet, with the outer GTP-U header removed, to the ingress (e.g., routing engine) with the destination interface set to “5G LAN inside” and the network instance set to “5G LAN group 1”. NOTE: Steps 6-7 can be omitted if the incoming packets are directly matched against the PDR of UE3's N4 session. However, such a PDR needs to be added to the N4 session of all UEs that may receive packets from Nx.
[0266] 8. UPF2 identifies the N4 session of UE3 by comparing the destination address of UE3 and the source interface set to "5G-LAN inside" with the PDR specified for the N4 session.
[0267] 9. UPF2 processes the FAR associated with that PDR and makes the packet available for UE3 to receive by adding an outer header to the packet set to the remote TEID assigned to UE2's PDU session, with "Destination Interface" set to "Access".
[0268] C. How to manage N4 (PFCP) sessions in a 5G LAN group When a packet is sent to the ingress with destination interface "5G LAN Inside", a lookup is performed using a PDR with source interface "5G LAN Inside". However, there are cases when the UPF cannot find a PDR that matches the packet, i.e. neither a PDR related to the N4 session when the UE is served by the same UPF (local switch scenario) nor a PDR for the N4 session (Nx based forwarding) created in this UPF to match traffic to and from 5G LAN group 1.
[0269] For example, as disclosed in Figure 18, UE1 wants to communicate with UE3, but the N4 session of its 5G LAN group 1 does not have PDR and FAR installed. In such a case, the UPF shall be instructed to report this to the SMF, which includes the following options: 1. Reactive ("pull") approach: Provision a default PDR with the lowest priority value in the 5G LAN group N4 session to match traffic received from "5G LAN inside" and capture unknown traffic. - Create a FAR and forward such traffic to the SMF. When the SMF receives such user plane traffic, it determines which UPF is serving the destination UE, and therefore provisions the associated PDR / FAR in the UPF forwarding the packet and in any intermediate UPFs (for potential communication from the UE served by that UPF to the same destination UE) so that the traffic can be forwarded to the UPF serving the destination UE. - Alternatively, provision a new URR with a new reporting trigger, preferably called "Unknown 5G LAN Traffic", and associate it with the default PDR, so that the UPF will send a PFCP Session Report Request message to report packets of UE-to-UE traffic to the SMF, i.e. packets to the destination UE IP address cannot be delivered. This will cause the SMF to provision the associated PDR1a / FAR1a to the UPF for the 5G LAN group 1 N4 session, and to any intermediate UPFs (for potential communication from a UE served by that UPF to the same destination UE) to be able to forward the traffic to the UPF serving the destination UE. (As shown in FIG. 14, when the SMF receives a query for the destination UE (UE2), it installs a PDR in the N4 session of 5G LAN group 1).
[0270] 2. Proactive ("push") approach: Provision a PDR for an N4 session in 5G LAN Group 1 for a UPF other than the one serving the UE when the UE is attached to the network. We propose to leave it up to the SMF implementation to decide whether to use a reactive or proactive approach. However, it should be noted that the proactive approach may result in a large amount of unnecessary N4 signaling, i.e., when UEs are served by different UPFs, PDRs will be provisioned to allow communication between UEs even though such UEs would never communicate with each other.
Claims
1. A method performed by a session management function (SMF) (208) of a 5G core network, comprising: generating a first packet detection rule (PDR) (304) associated with a first N4 session associated with a first UE (204, 218) or associated with a 5G LAN group, wherein the first PDR (304) includes a FAR identifier for identifying a first forwarding action rule (FAR) (306); generating a first FAR (306), where the first FAR (306) includes an indication that a protocol data unit (PDU) (301, 351) conforming to the first PDR (304) requires further ingress processing; providing the first PDR (304) and the first FAR (306) to a first user plane function (UPF) (206).
2. 2. The method of claim 1, wherein the SMF (208) provides the first PDR (304) to the first UPF (206) by sending a session request including the first PDR (304) to the first UPF (206).
3. The method according to claim 1 or 2, further comprising: generating a second PDR (310, 360) associated with a second N4 session, wherein the second PDR (310, 360) includes a FAR identifier for identifying a second FAR (312, 362); generating the second FAR (312, 362); providing the second PDR (310, 360) and the second FAR (312, 362) to the first UPF (206).
4. 4. The method of claim 3, wherein a destination interface information element (IE) of the second FAR (312, 362) is set to "Core", "Access", or "5G LAN Nx".
5. 5. The method of claim 3 or 4, wherein a network instance IE of the second FAR (312, 362) is set to a value that identifies a network domain specific to traffic of the 5G LAN group.
6. 6. The method of claim 4 or 5, wherein the second PDR (310, 360) is associated with an N4 session created for a specific 5G LAN group, and a destination interface IE of the second FAR (312, 362) is set to "5G LAN Nx".
7. 7. The method of claim 4, wherein the second PDR (310, 360) is associated with an N4 session associated with a second UE (204), and a destination interface IE of the second FAR (312) is set to "access".
8. A computer program comprising instructions which, when executed on at least one processor (1555), cause the at least one processor (1555) to perform a method according to any one of claims 1 to 7.
9. A computer readable storage medium storing the computer program according to claim 8.
10. An apparatus (1500) configured to perform the steps of the method according to any one of claims 1 to 7.
11. An SMF (208) configured to perform the steps of the method according to any one of claims 1 to 7.
Citation Information
Patent Citations
Session management method based on reallocation of PDU session anchor device, and device performing the session management method
US20180279180A1
Method, device and system for realizing service continuity
WO2018232759A1
