Enhancement of redundant transmission in 5g network

Abstract

To provide a policy and a parameter to a network in order to support a redundant transmission construction by using a dual connectivity (DC).SOLUTION: A method contains steps of: associating packet data unit (PDU) session pair information (PSPI) to both of a first PDU session and a second PDU session; transmitting the PSPI to a mobility administrative function (AMF) in a network by both of a first PDU session establishment message and a second PDU session establishment message; and transferring it to a first session administrative function (SMF) and a second SMF by the AMF. Such a construction enable an association of a radio access network (RAN) with two PDU sessions.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 118,110, filed November 25, 2020, and entitled “Enhancement To Redundant Transmission In 5G Network,” the contents of which are incorporated herein by reference. [Background technology]

[0002] The 3rd Generation Partnership Project (3GPP) develops technical standards for mobile communication network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "5G". 3GPP NR standard development is expected to continue and include the definition of next-generation radio access technologies (New RATs), which are expected to include new flexible radio access provisions below 7 GHz, and new ultra-mobile broadband radio access provisions above 7 GHz. Flexible radio access is expected to include new non-backward compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with divergent requirements. Ultra Mobile Broadband is expected to include cmWave and mmWave spectrum, providing ultra mobile broadband access opportunities for indoor applications and hotspots, for example. Notably, Ultra Mobile Broadband is expected to share a common design framework with sub-7 GHz Flexible Wireless Access, with centimeter wave and millimeter wave specific design optimizations.

[0003] This background information is provided to identify information believed by applicant to be potentially relevant, and is not necessarily intended, nor should it be construed, as an admission that any of the preceding information constitutes prior art. Summary of the Invention

[0004] Disclosed herein are methods, systems, and devices related to redundant transmission for URLLC applications, PDU session establishment or modification processes, or URSP enhancements for UL traffic duplication at the PDU layer. In particular, several problems associated with existing mechanisms for enabling and supporting redundant transmission as set forth herein are addressed. The disclosed subject matter may enhance redundant transmission mechanisms.

[0005] This specification discloses policy and parameter provisioning to the network to support redundant transmission configuration. How the RSN and redundant user plane requirements are linked, and a list of parameters and policy rules provided from the PCF to the SMF for redundant transmission decision and configuration are described in more detail. The AF may also provide input to the PCF, which may affect the parameters and policy rules.

[0006] In this specification, a procedure is disclosed in which a UE provides PDU session pair information to a core network, so that the PDU session pair information can be provided to a RAN node to enable dual connectivity based redundant transmission. The format of the PSPI and what information the PSPI contains, the procedure for PSPI generation and provisioning to a RAN node, and how the UE can determine to make a PDU session redundant based on an instruction from an application layer are described in more detail.

[0007] A method for PDU session modification for redundant transmission is disclosed herein. Possible triggers in different network entities (UE, RAN node, AF, and SMF) and procedures for disabling or stopping redundant transmission or continuing redundant transmission by replacing one of the PDU sessions in a session pair are described in more detail.

[0008] In this specification, an enhancement to the URSP rules is disclosed to enable the UE to perform traffic duplication and elimination at the PDU layer. The subject that the UE may decide to utilize redundancy, and the decision is made independently of the application layer, is described in more detail.

[0009] In one example, a method may include receiving configuration information for assigning packet data unit (PDU) session pair information (PSPI) to one or more PDU sessions, determining using the configuration information that a first PDU session and a second PDU session are associated, associating the first PSPI with the first PDU session and the second PDU session based on the configuration, sending to a network the PSPI in a first PDU session establishment message to establish the first PDU session, and sending to the network the PSPI in a second PDU session establishment message to establish the second PDU session.

[0010] This Summary is provided to introduce a selection of concepts in a simplified form, which are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, the claimed subject matter is not limited to limitations that solve any or all of the disadvantages noted in any part of this disclosure. [Brief description of the drawings]

[0011] A more detailed understanding may be had from the following detailed description, given by way of example in conjunction with the accompanying drawings, in which: [Figure 1] 1 illustrates an exemplary 5G system service-based architecture. [Diagram 2]1 illustrates an example non-roaming 5G system architecture in a reference point representation. [Diagram 3] 1 illustrates an exemplary user plane protocol stack. [Figure 4] 1 illustrates an example scenario for end-to-end redundant user plane paths using dual connectivity. [Diagram 5] 1 illustrates an exemplary redundant transmission with two N3 tunnels between the PSA UPF and a single NG-RAN node. [Figure 6] 1 illustrates an exemplary procedure for PSPI generation and provisioning. [Figure 7A] 1 illustrates an exemplary procedure for updating a PSPI due to a PDU session change / release. [Figure 7B] 1 illustrates an exemplary procedure for updating a PSPI due to a PDU session change / release. [Figure 8] 1 illustrates an example procedure for redundant transmission in a 5G network. [Figure 9] 1 illustrates an example user interface for configuring redundant transmission, a display of which may be generated based on a method, system, and device for redundant transmission in a wireless network. [Figure 10A] 1 illustrates an exemplary communication system. [Figure 10B] 1 illustrates an exemplary system including a RAN and a core network. [Figure 10C] 1 illustrates an exemplary system including a RAN and a core network. [Figure 10D] 1 illustrates an exemplary system including a RAN and a core network. [Figure 10E] 2 illustrates another exemplary communication system. [Figure 10F] 1 is a block diagram of an example apparatus or device, such as a WTRU. [Figure 10G] FIG. 1 is a block diagram of an exemplary computing system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] 5G Network Architecture FIG. 1 illustrates an example non-roaming reference architecture 5G system having a service-based interface in the control plane.

[0013] FIG. 2 illustrates the 5G system architecture for the non-roaming case, using a reference point representation that shows how the various network functions interact with each other.

[0014] End-to-end communication between applications in the UE and applications in the external network uses services provided by the 3GPP system and, optionally, by a Services Capability Server (SCS) residing in the DN.

[0015] User Plane Protocol Stack and PDU Sessions 5GC supports the PDU connection service, i.e. a service that provides exchange of PDUs between the UE and a data network identified by a Data Network Name (DNN). The PDU connection service is supported via a PDU session that is established upon request from the UE. PDU sessions are established (at UE request), modified (at UE and 5GC request), and released (at UE and 5GC request) using NAS SM signaling exchanged on the N1 interface between the UE and the SMF via the AMF. Upon request from an application server, 5GC can trigger a specific application in the UE. Upon receiving the trigger message, the UE passes it to the identified application in the UE. The identified application in the UE can establish a PDU session to a specific DNN.

[0016] A PDU session may be associated with an S-NSSAI or a DNN. In the PDU session establishment request sent to the network, the UE provides a PDU session identifier. The PDU session ID is an identifier that is unique per UE and is used to uniquely identify one of the UE's PDU sessions. The PDU session ID shall be stored in the UDM in order to support handover between 3GPP and non-3GPP accesses when different PLMNs are used for these two accesses.

[0017] Each PDU session supports a single PDU session type, i.e. the exchange of a single type of PDU requested by the UE when establishing the PDU session. The following PDU session types are defined: IPv4, IPv6, IPv4v6, Ethernet and Unstructured.

[0018] A UE may establish multiple PDU sessions simultaneously for the same or different data networks, via 3GPP and via non-3GPP access networks. A UE may establish multiple PDU sessions for the same data network and be served by different UPF terminations N6. A UE with multiple established PDU sessions may be served by different SMFs. The SMF serving a PDU session (e.g., anchor) does not change during the lifetime of the PDU session.

[0019] FIG. 3 shows the protocol stack for user plane transport associated with a PDU session.

[0020] Redundant PDU Sessions Redundant transmission for reliable communication is specified in TS 23.501 to enhance 5GS to support Ultra Reliable Low Latency Communication (URLLC). When a PDU session serves a URLLC QoS flow, the UE and SMF need to establish the PDU session as an always-on PDU session. An always-on PDU session is a PDU session for which user plane resources must be activated during each transition from CM-IDLE mode to CM-CONNECTED state. Based on an indication from higher layers, the UE may request to establish a PDU session as an always-on PDU session. The SMF decides whether a PDU session can be established as an always-on PDU session. There are three options specified in TS 23.501 to support URLLC reliable communication: Dual connectivity based on end-to-end redundant user plane paths Support for redundant transmission on N3 / N9 interfaces Support for redundant transmission at the transport layer

[0021] As described in TS 37.340, the NG-RAN may implement redundant user plane resources for two redundant PDU sessions with two NG-RAN nodes (i.e., a master NG-RAN and a secondary NG-RAN) or with a single NG-RAN node (for redundant transmission on the N3 / N9 interface). In all cases, there is a single N1 interface to the AMF.

[0022] Dual connectivity based on end-to-end redundant user plane paths Figure 4 shows an example user plane resource configuration for dual PDU sessions when redundancy is applied. The UE may set up two redundant PDU sessions on the 5G network such that the 5GS sets up user plane paths for the two redundant PDU sessions that are separated. The UE's subscription indicates whether the UE is allowed to have a redundant PDU session, and this indication is provided from the UDM to the SMF. One PDU session extends from the UE through the master NG-RAN to the UPF1 acting as a PDU session anchor, and the other PDU session extends from the UE through the secondary NG-RAN to the UPF2 acting as a PDU session anchor.

[0023] Based on these two PDU sessions, two independent user plane paths are set up: traffic via UPF1 and UPF2 may be routed towards the DN via different user plane nodes, but UPF1 and UPF2 connect to the same Data Network (DN).

[0024] The UE initiates the establishment of two redundant PDU sessions and provides a different combination of DNN and S-NSSAI for each PDU session. The SMF determines whether to process a PDU session redundantly based on the policy provided by the PCF for the PDU session and the combination of S-NSSAI, DNN, user subscription, and local policy configuration. In addition, the SMF determines a redundant sequence number (RSN) that distinguishes the PDU sessions to be processed redundantly. PDU sessions associated with different RSN values ​​shall be realized by different redundant UP resources. The RSN indicates to the NG-RAN that dual connectivity shall provide redundant user plane resources for a given PDU session. The request for redundant processing is made by indicating the RSN to the NG-RAN with per-session granularity. The value of the RSN parameter indicates the redundant user plane requirement for the PDU session.

[0025] The duplicated traffic from the application associated with the redundant PDU session is differentiated by two separate traffic descriptors, each in a separate URSP rule. These traffic descriptors must have different DNNs, IP or non-IP descriptors (e.g., MAC addresses, VLAN IDs) so that the two redundant PDU sessions match the RSDs of the separate URSP rules. How to utilize the duplicated paths end-to-end for redundant traffic delivery is outside the scope of 3GPP. It is possible to rely on higher layer protocols such as IEEE Time Sensitive Networking (TSN) or Frame Replication and Elimination for Reliability (FRER) to manage the duplication and elimination of redundant packets / frames on the duplicated paths, which can span both the 3GPP segment and possibly the fixed network segment. In other words, the higher layers are responsible for the duplication and elimination of traffic in this scenario.

[0026] Support for redundant transmission on N3 / N9 interfaces FIG. 5 shows a case where redundant transmission is performed only through the N3 interface.

[0027] If the reliability of the NG-RAN nodes, UPF, and CP NFs is high enough to meet the reliability requirements of the URLLC services served by these NFs, but the reliability of a single N3 tunnel is not considered high enough, for example, due to the deployment environment of the backhaul network, a redundant transmission may be deployed between the PSA UPF and the NG-RAN via two independent N3 tunnels associated with a single PDU session on different transport layer paths to increase its reliability.

[0028] To ensure that the two N3 tunnels are forwarded through separate transport layer paths, the SMF or PSA UPF needs to provide different routing information (e.g., different IP addresses or different network instances) in the tunnel information, which needs to be mapped to the separate transport layer paths according to the network deployment configuration. In response, the SMF indicates to the NG-RAN and PSA UPF that one of the two CN / AN tunnel information is used as the redundant tunnel for the PDU session. The redundant transmission using the two N3 / N9 tunnels is performed at QoS flow granularity and shares the same QoS flow ID.

[0029] When duplicate transmission is performed on the N3 / N9 interface, for each downlink packet of a QoS flow that the PSA UPF receives from the DN, the PSA UPF duplicates the packets and assigns them the same GTP-U sequence number for redundant transmission. The NG-RAN removes the duplicate packets based on the GTP-U sequence number, and then forwards the PDU to the UE.

[0030] For each uplink packet of a QoS flow that the NG-RAN receives from the UE, the NG-RAN duplicates the packets and assigns them the same GTP-U sequence number for redundant transmission. These packets are transmitted separately to the PSA UPF via two N3 tunnels. In response, the PSA UPF removes the duplicate packets based on the GTP-U sequence number.

[0031] Support for redundant transmission at the transport layer Redundant transmission can be supported in a 5G system without making any assumptions about the support of protocols such as IEEE FRER at the application layer (DN only) and at the same time without requiring redundant GTP-U tunnels over N3. The backhaul provides two separate transport paths between the UPF and the NG-RAN. The redundancy functions in the NG-RAN and the UPF utilize independent paths at the transport layer. Supporting redundant transmission at the transport layer does not require any impact on 3GPP protocols. The steps are as follows:

[0032] In the first step, the UE establishes a PDU session for the URLLC service. Based on the DNN, S-NSSAI, knowledge of supporting redundant transmission in the transport layer, and other factors described in section 6.3.3, the SMF selects a UPF that supports redundant transmission in the transport layer for the PDU session. One N3 GTP-U tunnel is established between the UPF and the NG-RAN.

[0033] In a second step, the knowledge to support redundant transmission at the transport layer can be configured in the SMF or configured in the UPF and then obtained by the SMF via N4 capability negotiation during the N4 association setup procedure.

[0034] In the third step, for DL ​​data transmission, the UPF sends DL packets on the N3 GTP-U tunnel. The redundancy function in the UPF duplicates the DL data on the transport layer. The redundancy function in the NG-RAN removes the received duplicate DL data and sends it to the NG-RAN.

[0035] In the fourth step, for UL data transmission, the NG-RAN sends the received UL packets on the N3 GTP-U tunnel, and the redundancy function in the NG-RAN performs redundancy processing on the backhaul transport layer. The redundancy function in the UPF removes the received duplicate UL data and sends it to the UPF.

[0036] System hardening for redundant PDU sessions Several possible enhancements have been identified for the existing redundant PDU session mechanism specified in TS 23.501. Specifically, the 3GPP SA2 working group lists several potential objectives for further enhancing the current redundant PDU session mechanism as shown in SP-200448:TEI17_SE_RPS-New WID:System enhancement for redundant PDU Session, as follows:

[0037] Regarding the first objective, it is disclosed that if the UE has knowledge of PDU session pair information for a redundant PDU session, the UE provides the PDU session pair information to the SMF(s), so that the SMF(s) can provide this information to the NG-RAN, and the NG-RAN can ultimately use this information for SN selection, and also gNB CU / DU selection. This allows the two PDU sessions to be established independently without any constraint on the selected SMF(s).

[0038] Regarding the second objective, when the UE releases one of the redundant PDU sessions and establishes a third PDU session, the previous PDU session pair information can be used for coordination with the newly established PDU session.

[0039] Regarding the third objective, it needs to be clarified how the UE obtains knowledge of the PDU session pair information for the redundant PDU sessions.

[0040] Consideration Redundant PDU sessions have been defined to support reliable communication for URLLC applications. In dual connectivity (DC) based scenarios, a new parameter called RSN is defined and associated with redundantly processed PDU sessions so that network functions and RAN nodes can know which PDU sessions are redundant PDU sessions and allocate user plane resources for the PDU sessions accordingly. In addition, the RSN is determined by the SMF and is used to indicate and distinguish redundantly processed PDU sessions. In other words, different RSN values ​​indicate redundant user plane requirements, which results in different but redundant user plane resource allocations for PDU sessions. However, there are still some issues that are not addressed, such as:

[0041] Regarding the first problem, it is not defined how to assign RSN values ​​to indicate a redundant user plane requirement. In fact, the meaning of a redundant user plane requirement is not defined. In the current specification, there is no mechanism specified to indicate how a redundant user plane requirement is defined and whether it should be associated with a specific standardized attribute such as a QoS requirement / parameter.

[0042] Regarding the second problem, TS 23.501 states that the SMF determines whether to process a PDU session redundantly based on a policy provided by the PCF. However, current network design has the SMF make this determination based on local configuration. This approach is not very scalable and would be preferable if a policy engine (i.e., PCF) could be used to help guide the SMF in making this determination. The SMF determines the RSN value based on local configuration, and overall system performance could be improved if the SMF assigned the RSN so that the RAN can use the RSN to determine which PDU sessions are linked.

[0043] Regarding the third problem, the RSN can only indicate that a PDU session is processed redundantly with a specific redundant user plane requirement. However, it does not indicate which two PDU sessions are associated together as a pair of redundant PDU sessions for redundant transmission. In other words, the network function and the RAN node do not know which two PDU sessions are bound together for redundant transmission. This can be important for DC-based scenarios where the master RAN node needs information to select a secondary RAN node by considering PDU session context information.

[0044] Regarding the fourth problem, in order to provide the RAN node with PDU Session Pair Information (PSPI), the network needs to have such information. However, there is no defined mechanism on how the network (e.g., SMF) can obtain this information. Since the two sessions are managed independently, it is highly likely that two separate SMFs manage the two PDU sessions. It cannot be assumed that these two SMFs can communicate. There is no existing mechanism that allows these two SMFs to exchange such session management information. In fact, each SMF is not aware that another redundant PDU session has been established.

[0045] Regarding the fifth problem, how to provide PDU session pair information to other network entities (e.g., RAN nodes and AFs) is not addressed. Typically, the SMF should be responsible for providing such session management related information. However, as mentioned above, the SMF may not be able to provide such information.

[0046] Regarding the sixth problem, although only the UE can trigger the redundant PDU session establishment / modification, an application server (e.g., AF or SCS / AS) should be able to do so by providing the network (e.g., SMF or PCF) with the necessary information for policy generation and parameter provisioning. However, no mechanism is defined that allows the application server to do so. In addition, the application server may request to be notified when two redundant PDU sessions are established for application traffic. Considering the fact that two different SMFs may manage each PDU session, it is desirable to specify some mechanism for how the application server subscribes to which network entity for such an event and how the notification is delivered to the AF or SCS / AS.

[0047] Regarding the seventh problem, another problem is about redundant session modification. When the network / UE / application server decides to stop redundant transmission by releasing / deactivating one PDU session, and then later decides to associate the remaining PDU session with another PDU session for redundant transmission, the RAN node and anchor UPF need to be notified to adjust the user plane resource allocation and traffic duplication / removal behavior. This can be done mainly based on RSN and PDU session pair information. However, there is no existing mechanism to provide this information for redundant transmission during the PDU session modification procedure.

[0048] Regarding the eighth problem, the existing mechanisms rely on upper layers (e.g., application layer and transport layer) for traffic duplication and elimination for DC-based redundant transmission. In other words, for UL traffic, the UE simply applies two separate URSP rules to find two redundant PDU sessions to forward the same UL application traffic, respectively. It would be more efficient if traffic duplication and elimination could be handled at the PDU layer. This approach could enable redundant transmission more dynamically. For example, the UE or UPF could dynamically determine whether to transmit application traffic to one PDU session (i.e., no redundant transmission) or to two PDU sessions (i.e., redundant transmission) based on the network condition. Under the current URSP mechanism, it is not possible for the UE to transmit the same UL traffic to two PDU sessions. Therefore, some URSP enhancement is needed so that the UE can duplicate traffic and transmit it to two PDU sessions.

[0049] Considering the above problems, some new information elements and new mechanisms are desired to enhance the existing redundant PDU session methods.

[0050] This specification discloses redundant transmission for URLLC applications in 5GC. In particular, some problems associated with existing mechanisms for enabling and supporting redundant transmission as specified herein are addressed. To enhance the redundant transmission mechanism, the following ideas are disclosed:

[0051] The subject matter disclosed herein may be based on the following principles. In the first principle, since the RSN is used only for dual connectivity (DC)-based redundant transmission, the disclosed approach can be assumed to be specific to the DC-based mechanism unless other mechanisms (i.e., N3 / N9 tunnel-based) are explicitly mentioned. Furthermore, the PDU session pair information is also defined only for the DC-based mechanism. However, the concept of user plane redundancy requirements is general to all mechanisms for supporting redundant transmission (i.e., DC-based, N3 / N9 tunnel-based, and transport layer support). In the second principle, the PDU sessions established in the dual connectivity-based mechanism are managed by different SMFs (e.g., at least two), and these SMFs may not directly communicate with each other.

[0052] Redundant User Plane Requirements and RSN Policy and parameter provisioning from the PCF / AF for redundant transmission is disclosed below. The RSN indicates the redundant user plane requirement and can be configured in multiple ways. For example, it can be configured to indicate one or more specific performance metric requirements for application data forwarding, such as packet loss rate or delay threshold. Thus, the redundant user plane requirement can be tied to a specific QoS parameter or characteristic to reflect the performance metric. The PCF provides this mapping to the SMF, which associates the RSN value with a PDU session for redundant transmission. The redundant user plane requirement can be configured per application traffic identified by an application ID, per UE, per PDU session, per QoS flow, or per DNN / S-NSSAI.

[0053] Policy and parameter provisioning for redundant transmission - Patents.com The SMF needs some information to decide if a PDU session should be a redundant PDU session or not, and the RSN value to indicate the redundant user plane requirement. The PCF can provide these policies and parameters to the SMF. The PCF can provide the following information to the SMF so that the SMF can make a decision regarding redundant transmission:

[0054] First, the information may include a set of DNN and S-NSSAI combinations that may require redundant transmission support.

[0055] Second, the information may include an indication to indicate, for each set of DNN and S-NSSAI, which redundant transmission options are supported (e.g., DC-based, N3 / N9 tunnel-based, or whether transport layer redundant transmission may be required). If multiple options are supported, each option may be associated with a preference value indicating a preference for each option.

[0056] Third, the information may include a mapping between QoS requirements (indicated via one or more QoS parameters or characteristics, e.g., 5QI, maximum packet loss rate, packet delay budget) or service requirements and RSN values ​​or ranges of RSN values. This may be used by the SMF to set the RSN value to reflect the redundant user plane requirements. Alternatively, the PCF may provide a mapping between the SDF and the RSN values ​​or ranges of RSN values. In particular, the PCF may set some thresholds for some performance metrics (e.g., QoS characteristics or parameters) for the SMF so that the SMF can set the RSN value.

[0057] Fourth, the information may include PLMN information (e.g., PLMN ID) or location information (e.g., TA, RA, or geographic location area), which may be provided by the PCF to indicate where redundant transmission can be applied for a given DNN and S-NSSAI.

[0058] Fifth, the information can be from reporting events / conditions that may trigger the SMF to inform the PCF / AF about any changes in the redundant transmission configuration, for example, when redundant transmission is enabled / disabled for application traffic, when one of the redundant PDU sessions or one of the N3 / N9 tunnels is released or deactivated, when the QoS in one of the redundant sessions / tunnels is not met or requires some change, when the PDU Session Pair Information (PSPI) is updated for any reason.

[0059] Sixth, the information may be about how the PSPI is constructed. For example, the PCF may indicate that the PSPI should include two SMF IDs, each managing a PDU session, in addition to two PDU session IDs associated with each other for redundant transmission. Alternatively, the PSPI may be a number or ID (e.g., a PDU session pair ID) that is used as a reference to the session information (session ID+SMF ID). Further details about the PSPI are disclosed herein.

[0060] The seventh information may be information about where the PSPI is stored. The PSPI information may be stored in the UDM / UDR or the SMF. When two SMFs manage a pair of PDU sessions respectively, storing the PSPI in the UDM / UDR may make it more convenient for other network functions and AFs to retrieve the PSPI as part of the UE context.

[0061] Eighth, the information may be about policies on how to manage the PSPI. It indicates whether the UE or the SMF is in charge of generating and updating the PSPI. The PCF may provide the above information to the SMF in the PCC rules or PDU session related policy information. The AF may also input some application related information to the network (e.g., PCF) to influence the redundant PDU session policy / parameter provisioning. For example, the AF may directly request redundant transmission for (a group of) UEs for a certain type of application traffic in a certain location, in a certain time period, or when the UE is moving. The AF may indicate to the PCF that redundant transmission is preferred or necessary for a specific application (e.g., identified by application ID, IP address of the application server) associated with a class of QoS requirement (e.g., 5QI, maximum packet loss rate, packet delay budget) and corresponding redundant user plane requirement. One option to do this is to enhance the procedure of AF's influence on traffic routing, where the AF provides information to the PCF via the NEF. Information from the AF can help the PCF generate PCC rules related to redundant transmission that are sent to the SMF.

[0062] When the SMF receives a PDU session establishment / modification request, the SMF determines whether redundant transmission is required based on the policy rules and information provided by the PCF. Then, the SMF selects a UPF that supports redundant transmission. In particular, the SMF may consider the following information for UPF selection related to redundant transmission: first, whether the UPF can perform traffic duplication / elimination to support N3 / N9-based redundant transmission, and second, whether the UPF has the ability to support RSN for DC-based redundant transmission.

[0063] It should be noted that the PCF provides policies and parameters to the SMF to manage redundant transmission in a static manner, e.g., these policies or parameters are not frequently changed or updated, whereas the SMF may consult with other network functions such as the UDM / UDR 209, the AMF 203, the UPF 206, and the NWDAF in real time about the network state, the UE's subscription data, and the user plane performance when determining whether redundant transmission is required or what level of redundant user plane requirements is required.

[0064] How to provision PDU Session Pair Information (PSPI) As discussed herein, the RSN does not indicate which two PDU sessions are linked together for DC-based redundant transmission. This PDU session pair information may be important for a RAN node to establish dual connectivity and enable redundant transmission. Disclosed herein is subject matter related to how to construct a PSPI, what information is included in the PSPI, and how to provide the PSPI to a RAN node (e.g., the master RAN 202).

[0065] In case of DC-based redundant transmission, each PDU session may be established by a different SMF. This implies that these two SMFs may not know each other, and thus the UE 201 may be the first entity to know that at least one PDU session is linked together, before any other network function. It is disclosed that the UE 201 generates a PSPI and provides it to the SMF 204, which further transmits the PSPI to the RAN node via an N2 SM message.

[0066] 6 shows an exemplary procedure of PSPI generation and provisioning to a RAN node, where it is generally assumed that different SMFs (e.g., at least two) are selected to manage different PDU sessions, respectively.

[0067] Step 220: PDU session 1 is established by the SMF 204 and it is determined that redundant transmission is required. Therefore, the SMF 204 allocates PDU session 1 to RSN 1. At this time, the RAN node knows that dual connectivity is required to support redundant transmission, but there is only one PDU session information, so the RAN node waits for another PDU session information or PSPI to establish dual connectivity.

[0068] Step 221: The upper layer of the UE 201 sends a request to the NAS layer to establish another PDU session for the same application. However, a different combination of DNN and S-NSSAI is provided. The UE 201 sends a PDU session establishment request including PDU session ID 2 and a different combination of DNN and S-NSSAI to the AMF 203 via the RAN node. This implies that at least the DNN or S-NSSAI is different from the one used for PDU session 1 (however, they may be the same). The AMF 203 selects the SMF 205 to manage the session establishment. The UE 201 may explicitly indicate that redundant transmission is required for a given DNN and S-NSSAI in the request.

[0069] Step 222: Based on the policies and parameters provided by the PCF and the local policy configuration by the operator, the SMF 205 determines that redundant transmission is necessary and assigns RSN2 to PDU Session ID2. Then, the SMF 205 selects the UPF 207 as the anchor point of the PDU Session 2. Note that the SMF 205 may contact the UDM / UDR 209 to retrieve subscription data of the UE 201 to verify whether the UE 201 can tolerate redundant transmission. In addition, the SMF 205 may contact the PCF to retrieve any policies related to redundant transmission if it does not have enough information to make a decision or to generate an RSN.

[0070] Step 223: The SMF 205 sends an N4 session establishment or modification request message to the UPF 207.

[0071] Step 224: Then, the SMF 205 sends an N2 SM message to the RAN node. The N2 SM message includes PDU Session ID2, QoS Profile, RSN2, and the service area of ​​the SMF 205. The master RAN node 202 knows that PDU Session 2 needs to be processed redundantly with dual connectivity because the RSN is associated with it. However, at this stage, even though the RAN node knows the context information of PDU Session 1 during the PDU session establishment (i.e., step 220), the RAN node does not know which session is associated with PDU Session 2 for redundant transmission. A NAS SM accept message is also included and forwarded to the UE 201.

[0072] Step 225: The NAS SM accept message is forwarded to the UE 201 together with RSN2.

[0073] Step 226: The UE 201 generates PSPI information. Specifically, based on the existing DC-based redundant transmission mechanism, the upper layer of the UE 201 knows that the PDU sessions 1 and 2 are linked together to handle traffic duplication / elimination and provide redundant transmission for the same application traffic. The upper layer of the UE 201 constructs a PSPI and sends it to the NAS layer. The UE 201 associates the PSPI with the two PDU session IDs generated by the UE 201 when it requests to establish a PDU session. In the DC, both RAN nodes in the DC communicate with the two SMFs through a single N2 interface. Providing the SMF IDs can help the RAN nodes contact the SMFs for session management signaling, such as QoS notification.

[0074] Alternatively, the PSPI can be a number or ID (e.g., a PDU session pair ID) assigned by the UE 201. The UE 201 can provide the same PSPI to the network for redundant PDU sessions. In this option, the PSPI stored in the UDM / UDR 209 is used as a reference to the PDU session IDs that are linked together for redundant transmission.

[0075] Step 227: The UE 201 sends the PSPI information to the AMF 203 via a NAS message. The AMF 203 can then send the PSPI to the UDM / UDR 209, where the PSPI is stored as part of the UE context. Storing the PSPI in the UDM / UDR 209 makes it easier for other network entities to retrieve the PSPI of the UE 201, especially when two different SMFs manage the two sessions respectively. In addition, the AMF 203 may send the PSPI to the SMF 204 or SMF 205 based on a policy configuration by the operator. In this case, the SMF may contact the UDR / UDM to store the PSPI as a UE context.

[0076] Step 228: The AMF 203 or SMF sends the PSPI to the RAN node using an N2 message.

[0077] Step 229: Using the PSPI, the RAN node starts operating as the master RAN node 202 and selects a secondary RAN node based in part on the PSPI to establish dual connectivity for PDU session 2. Note that how to select a secondary RAN node and establish dual connectivity is beyond the scope of this specification.

[0078] Step 230: The master RAN node 202 sends an N2 SM message including N3 tunnel information to the SMF 205 via the AMF 203 for forwarding user plane data between the secondary RAN node and the UPF 207.

[0079] Step 231: Optionally, if the AF 208 or application server subscribes to get a notification when redundant transmission is enabled for its traffic, the SMF 204 or SMF 205 may send the notification. The AF 208 may send a subscription request to the PCF / SMF through the procedure of the impact of the AF 208 on traffic routing. Alternatively, the UE 201 may send the notification to the AF / AS 208 by using application layer signaling. The notification includes the PSPI.

[0080] In "Error! Reference Not Found", UE 201 generates the PSPI after PDU session 2 is established. Thus, the network does not know initially that the PDU sessions are linked. UE 201 may later determine to send a NAS message (e.g., PDU Session Change message) for each of the two PDU sessions. UE 201 may determine to send the NAS message based on a request for redundant transmission from the application layer (e.g., an indication from the application layer that a redundant PDU session is needed may come from the TE to the ME via an AT command). The PDU Session Change message includes the same PSI. Each SMF then forwards the PSI in an N2 message (via AMF 203) to the RAN node. In this way, the RAN node knows which two PDU sessions are linked.

[0081] The UE 201 may also generate and provide a PSPI to the network in a PDU session establishment request for each PDU session. In this scenario, the UE 201 first determines that a redundant transmission is required based on a request for redundant transmission from the application layer (e.g., an indication from the application layer that a redundant PDU session is required may come from the TE to the ME via an AT command), and the UE 201 generates two PDU session IDs and a PSPI. Specifically, in this case, the NAS layer of the UE 201 generates the PSPI. The UE 201 then sends a PDU session establishment request to the network, which includes two PDU session IDs, two sets of combinations of DNN and S-NSSAI, a PSPI that links the two PDU session IDs, and an indication that redundancy is required. Thus, the network is first aware that the PDU sessions are linked. The PDU session modification message includes the same PSI. Then, each SMF forwards the PSI to the RAN node in an N2 message (via the AMF 203). In this way, the RAN node knows which two PDU sessions are linked in a PDU session establishment.

[0082] Alternatively, the UE 201 may provide only two PDU session IDs and an indication that redundancy is required. The network (e.g., SMF or AMF 203) may generate a PSPI upon receiving a PDU session establishment request from the UE 201 with the above information. The AMF 203 may still select two different SMFs to manage the respective PDU sessions in this scenario. In another scenario, the UE 201 may send the PSPI and redundant transmission indication during a second PDU session establishment request.

[0083] Procedure for modifying PDU sessions for redundant transmission This specification discloses a procedure for managing PSPI and related information when redundant transmission is disabled because one of the PDU sessions needs to be modified or released. Specifically, there are several possible cases: 1) the network, UE or AF decides to disable redundant transmission by releasing or deactivating one of the PDU sessions, or 2) the network, UE or decision AF changes the redundant PDU session pair (e.g., release / deactivate one and link the remaining one with another PDU session), which triggers an update of the PDU session pair information (PSPI).

[0084] 7A-7B show a procedure for updating a PSPI triggered by a PDU session change or release.

[0085] Step 240: Two PDU sessions are established for redundant transmission. Note that different SMFs and UPFs are used, although SMF 205 and UPF 207 are not shown in the figure. PDU session 1 is used as an example for explanation.

[0086] There are several possible scenarios (four are listed below) that trigger the procedure of invalidating / updating redundant transmissions.

[0087] Case 1: The UE 201 triggers the process.

[0088] Step 241A: UE 201 may trigger the process based on a request from the application layer. For example, the application traffic is terminated or the application traffic no longer requires redundancy. Furthermore, UE 201 may trigger the process due to a network condition. For example, UE 201 wants to modify or release PDU session 1 and then associate PDU session 2 with another session for redundant transmission. This may be because UE 201 has moved out of the SMF 204 service area or PDU session 1 does not meet the requirements of the application traffic.

[0089] Step 241B: As a result, UE 201 sends a PDU session modification or release request message to SMF 204. UE 201 provides the PSPI, the ID of PDU session 1, and the combination of DNN and S-NSSAI. UE 201 may provide an indication of whether it wants to stop the redundant transmission or continue the redundant transmission by modifying PDU session 1 or by replacing PDU session 1 with another session for redundant transmission. Note that if UE 201 wants to link PDU session 2 with another PDU session, the PSPI is updated by UE 201 to link PDU session 2 and another PDU session together. If it is a new PDU session, UE 201 generates and provides a new PDU session ID and requests a session establishment process accordingly.

[0090] Case 2: The RAN node triggers the process.

[0091] Step 242A: The RAN node cannot directly decide to stop or disable the redundant transmission, but the RAN node may trigger a PDU session modification process to trigger the redundant transmission stop. For example, a handover is required for the UE, or the QoS of PDU session 1 is not satisfied, or there is a radio link failure. In these cases, the RAN triggers a PDU session modification process to update the redundant transmission operation, which further triggers a PSPI update. Note that the RAN node does not generate or update the PSPI. The UE 201 or the SMF may perform the PSPI generation or update.

[0092] Step 242B: The master RAN node 202 sends an N2 SM message to the SMF 204 to request modification of PDU session 1. The message includes the ID of PDU session 1, the PSPI, and the cause of the PDU session modification request. The cause of the PDU session modification can help the SMF decide whether to stop the redundant transmission by modifying PDU session 1 or by replacing PDU session 1 with another PDU session, or to continue the redundant transmission.

[0093] Step 242C: AMF203 forwards the PDU session change message to SMF204.

[0094] Case 3: The AF 208 or the application server triggers the process.

[0095] Step 243A: The AF 208 may trigger the process due to several possible events, for example, the AF 208 terminates application traffic that requires redundant transmission, the application traffic has lowered QoS requirements, and therefore redundant transmission is not required.

[0096] Step 243B: The AF 208 sends a request to the PCF to inform the SMF to deactivate or stop the redundant transmission, including the PSPI, PDU session ID, UE ID, DNN, and the cause of the request. The cause helps the SMF determine how to handle PDU session 1, i.e., release or modify the PDU session. In addition, the 5GC may trigger the application to start in the UE 201, and may indicate that redundant transmission is required based on a request from the AF 208 or the application server, and then the UE 201 triggers the redundant transmission for the application traffic by requesting to establish a PDU session to a specific DNN with the S-NSSAI.

[0097] Case 4: A network function (e.g., SMF) triggers the process.

[0098] Step 244: A network function such as the SMF 204 may also trigger a process to stop redundant transmission or update the redundant transmission configuration. This may be due to several events, such as out-of-SMF service area due to UE mobility, user plane congestion in the PDU session, etc. In addition, the NWDAF may provide the network function with network performance statistics that are used as input to determine whether to trigger the process.

[0099] Step 245: The SMF 204 sends an N4 session modify or release request to the UPF 206 depending on whether the SMF decides to modify PDU session 1 or release the session.

[0100] Step 246: If the SMF does not receive the PSPI in the previous step, i.e. the UE, the RAN node, or the AF 208 does not provide the PSPI but the PSPI needs to be updated because PDU session 1 is released or replaced to support redundant transmission, the SMF retrieves the PSPI from the UDR / UDM as the UE context where it assumes the PSPI is stored.

[0101] Step 247: If the SMF is responsible for generating and updating the PSPI, the SMF updates the PSPI. For example, if the redundant transmission is stopped / disabled, the SMF may delete the PSPI. If the PDU session 1 is replaced by another session to continue the redundant transmission, the SMF may update the PDU session IDs linked together in the PSPI. If the UE 201 is responsible for managing the PSPI, this step is skipped.

[0102] Step 248: The SMF sends an N2 SM message to the master RAN node 202 via the AMF 203 with the modification / release notification of PDU session 1 and an indication of whether the redundant transmission is disabled or not. If the redundant transmission is to continue in another PDU session replacing PDU session 1, the SMF provides a new PSPI linking the new PDU session with PDU session 2. Within the N2 message, the SMF also encapsulates a NAS message addressed to the UE. The NAS message can be a PDU session modification notification or a response, depending on which entity initially triggers the process. The NAS message can include the updated PSPI if the SMF updates the PSPI.

[0103] Step 249: The master RAN node 202 forwards a NAS message to the UE, where the NAS message includes the modified PDU session information. If the SMF manages the PSPI, the NAS message further includes the updated PSPI or an indication of whether the redundant transmission has been disabled. If the SMF decides to replace PDU session 1 with another PDU session to continue the redundant transmission, the SMF also provides session context information in the NAS message, such as PSU session ID, QoS rules, and other session context information.

[0104] Step 250: If the UE 201 is responsible for managing and updating the PSPI, the UE 201 updates or deletes the PSPI based on the session modification information provided by the SMF. Specifically, if the redundant transmission stops, the UE 201 deletes the PSPI. If the redundant transmission continues but the PDU session 1 is replaced by another session, the UE 201 updates the PSPI by linking the new PDU session with the PDU session 2.

[0105] Step 251: If the UE 201 is responsible for managing the PSPI, the UE 201 sends an updated PSPI or a PSPI deletion notification to the SMF via a NAS message.

[0106] Step 252: The SMF optionally sends the updated PSPI to the UDR / UDM for storage as part of the UE context.

[0107] Step 253: The SMF sends a PSPI update or removal notification to the master RAN node 202 so that the RAN node can adjust user plane resources in the wireless network. The master RAN node 202 may also replace the secondary RAN node with another RAN node.

[0108] Step 254: The SMF sends a PSPI update or deletion notification to the AF, which is optional and depends on whether the AF 208 subscribes to PSPI updates or deletions or configuration by the PCF.

[0109] URSP enhancements to allow UL traffic duplication at the PDU layer It has been described herein that the UE 201 may determine to provide a PSPI based on a request from an application layer (e.g., based on an AT command). Alternatively, the UE 201 may be configured to detect when some application layer traffic should be duplicated over multiple PDU sessions, and the UE 201 may perform traffic duplication at the PDU layer. When the UE 201 detects that some application layer traffic should be duplicated over multiple PDU sessions, the UE 201 may use the procedure previously described to establish a redundant PDU session.

[0110] In a first example of how UE 201 may detect that certain application layer traffic should be replicated over multiple PDU sessions, UE 201 may be configured with a URSP rule that includes an indication that traffic associated with the URSP rule should be replicated over multiple PDU sessions. In this example, the URSP rule may indicate whether DC-based replication or N3 / N9 replication is required. If DC-based replication is required, UE 201 may establish two PDU sessions as described above and replicate the application traffic at the PDU layer over the multiple PDU sessions.

[0111] The UE 201 may use the RSD associated with the URSP rule to establish two PDU sessions for the associated traffic. The UE 201 may use the highest priority RSD to attempt to establish a redundant PDU session until it can establish two PDU sessions. Alternatively, the URSP rule may include multiple sets of RSDs (one for each PDU session). The UE 201 may behave in such a way that if the UE 201 can establish only one PDU session and cannot establish a second PDU session, the UE 201 continues only one PDU session. Alternatively, the UE 201 may behave in such a way that if the establishment of only one PDU session is successful, the UE 201 terminates the first PDU session and indicates to the application that the PDU session establishment was unsuccessful (or tries a lower priority URSP rule). Whether the UE 201 continues only one PDU session or multiple PDU sessions may be based on the implementation of the UE 201 or based on an indication in the URSP rule.

[0112] If the URSP rule indicates that N3 / N9 duplication is required, the UE 201 may indicate to the SMF that N3 / N9 duplication is required for the PDU session. Specifically, adding two new parameters to the traffic descriptor of the URSP rule is disclosed.

[0113] First parameter, redundant transmission indicator: This indicator indicates whether redundant transmission is required for the traffic. If this indication is included, an indicative indication may be used to indicate whether the traffic may be transmitted over one PDU session if only one PDU session is successfully established.

[0114] The second parameter, N3 / N9 redundancy indicator: This indicator indicates whether DC-based, N3 / N9 tunnel-based, or transport layer redundant transmission is required.

[0115] These two attributes or indicators in the URSP rule can help the UE 201 determine that redundant transmission is required for certain traffic and include an indication in the PDU session establishment request message.

[0116] Alternatively, the above attribute can be added to the route selection descriptor so that UE201 knows that it needs to replicate traffic identified by the combination of DNN and S-NSSAI described in the RSD.

[0117] The configuration of these indications in the URSP may come from the PCF, which obtains information from the AF208 or an application server indicating that redundant transmission is required for application traffic identified by the IP address of the DNN and / or AS.

[0118] In another example, the UE 201 may indicate to the SMF that the UE 201 is capable of supporting DC-based duplication. This indication may be sent to the SMF during PDU session establishment. The SMF may indicate to the UE in the PDU session establishment acceptance that DC-based duplication should be applied. The UE 201 may then establish a redundant PDU session as previously described. As previously described, traffic duplication may be performed by the UE 201 for UL traffic in the PDU layer, and duplication elimination may be performed for DL ​​traffic in the PDU layer.

[0119] FIG. 8 shows an example procedure for redundant transmission in a 5G network. In step 261, the UE 201 may receive configuration information for assigning a PDU session pair information (PSPI) to a PDU session, where the PSPI may be a number. The configuration information may be received in a URSP rule or an AT command. An upper layer may determine the PSPI and provide it to the UE 201 via the AT command. The URSP rule includes a redundant transmission indicator. The redundant transmission indicator may be part of a route selection descriptor (RSD) in the URSP rule.

[0120] In step 262, the configuration information can be used to determine that the first PDU session and the second PDU session are associated. PDU sessions can be considered associated if both PDU sessions are used to transmit data from the same application (e.g., if the application transmits the same data over both PDU sessions to achieve redundancy) or if both PDU sessions are used to receive data for the same application (e.g., if the same application data is received over both PDU sessions (e.g., application data is duplicated to achieve redundancy)).

[0121] In step 263, the configuration information may be used to determine to assign the same PSPI (e.g., the first PSPI) to the first PDU session and the second PDU session.

[0122] In step 264, the PSPI may be sent to the network (e.g., SMF 204) in a first PDU session establishment message to establish the first PDU session.

[0123] In step 265, the PSPI may be sent to the network in a second PDU session establishment message to establish a second PDU session. The first PDU session or the second PDU session may be associated with a redundant transmission, or more specifically, a dual connectivity redundant transmission. The first PDU session or the second PDU session may be associated with one or more different combinations of DNN or S-NSSAI. The first PDU session establishment message or the second PDU session establishment message may each include an indication that redundancy is required.

[0124] The parameters involved in the redundant transmission operation may be provisioned through a user interface by an end user (e.g., UE 201), a network operator, or an application service provider. A user interface may be implemented to configure or program those parameters with default values ​​and to enable or disable redundant transmission. An exemplary user interface is shown in FIG. 9. The progress of any of the steps discussed herein (e.g., messages sent or success of a step) may be displayed. Additionally, a graphical output may be displayed on the display interface of FIG. 9. The graphical output may be a topology of devices implementing the methods, systems, and devices of redundant transmission in wireless networks, a graphical output of the progress of any method or system discussed herein, etc.

[0125] It is understood that the entities performing the steps depicted herein, such as in Figures 7-9, may be logical entities. The steps may be stored in a memory of and executed on a processor of a device, server, or computer system, such as that depicted in Figure 10F or 10G. It is contemplated to skip steps, combine steps, or add steps among the exemplary methods (e.g., Figures 7-9) disclosed herein.

[0126] Table 1 or Table 2 are definitions or abbreviations of the subject matter disclosed herein.

[0127] [Table 1]

[0128] [Table 2]

[0129] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "5G". 3GPP NR standard development is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include new flexible radio access provisions below 7 GHz, and new ultra mobile broadband radio access provisions above 7 GHz. Flexible radio access is expected to include new non-backward compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with divergent requirements. Ultra mobile broadband is expected to include cmWave and mmWave spectrum, which provide ultra mobile broadband access opportunities for indoor applications and hotspots, for example. In particular, Ultra Mobile Broadband is expected to share a common design framework with sub-7 GHz Flexible Radio Access, with centimeter-wave and millimeter-wave specific design optimizations.

[0130] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration, and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which may include any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, e-call for automobiles, disaster alerts, real-time gaming, multi-party video calling, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and more are contemplated herein.

[0131] 10A illustrates an example communication system 100 in which methods and apparatus for redundant transmission in a wireless network (e.g., 5G) may be used, such as the systems and methods described and claimed herein and shown in FIGs. 1-7. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, or 102g, which may be referred to generally or collectively as a WTRU 102 or multiple WTRUs 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, a V2X server, a V2X function, a ProSe server, a ProSe function, an IoT service, video streaming, or edge computing.

[0132] It will be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be any type of apparatus or device configured to operate or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g may be depicted as a handheld wireless communications device in FIG. 10A, 10B, 10C, 10D, 10E, or 10F, it should be understood that in the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to receive or transmit wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics device, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, a bus, a truck, a train, or a plane, or the like.

[0133] The communication system 100 may also include a base station 114a and a base station 114b. In the example of FIG. 10A, each base station 114a and 114b is illustrated as a single element. In reality, the base stations 114a and 114b may include any number of interconnected base stations or network elements. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, or other networks 112. Similarly, the base station 114b may be any type of device configured to interface wired or wirelessly with at least one of the Remote Radio Heads (RRHs) 118a, 118b, the Transmission and Reception Points (TRPs) 119a, 119b, or the Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, or the network server 113. The RRHs 118a, 118b may be any type of device configured to interface wirelessly with at least one of the WTRUs 102, e.g., the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, or the other networks 112.

[0134] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, or the network services 113. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, or the like.

[0135] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), a relay node, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations or network elements (not shown), such as a BSC, an RNC, a relay node, etc. The base station 114a may be configured to transmit or receive wireless signals within a particular geographical area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit or receive wired or wireless signals within a particular geographical area, which may be referred to as a cell (not shown) for the methods, systems, and devices for redundant transmission in a wireless network as disclosed herein. Similarly, the base station 114b may be configured to transmit or receive wired or wireless signals within a particular geographical area, which may be referred to as a cell (not shown). A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in one example, the base station 114a may include three transceivers, e.g., one transceiver for each sector of the cell. In one example, the base station 114a may employ multiple-input multiple output (MIMO) technology and thus utilize multiple transceivers for each sector of the cell.

[0136] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over air interfaces 115 / 116 / 117, which may be any suitable wireless communication links (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interfaces 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0137] The base station 114b may communicate with one or more of the RRHs 118a, 118b, the TRPs 119a, 119b, or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communications link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0138] The RRHs 118a, 118b, the TRPs 119a, 119b, or the RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over the air interface 115c / 116c / 117c, which may be any suitable wireless communications link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0139] The WTRUs 102a, 102b, 102c, 102d, 102e, or 102f may communicate with one another over an air interface 115d / 116d / 117d (e.g., sidelink communications), which may be any suitable wireless communications link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0140] The communications system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a of the RAN 103 / 104 / 105 and the RRHs 118a, 118b, TRPs 119a, 119b, and RSUs 120a, 120b of the WTRUs 102a, 102b, 102c, or the RANs 103b / 104b / 105b, and the WTRUs 102c, 102d, 102e, 102f may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS), Terrestrial Radio Access (UTRA), etc., which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) or High-Speed ​​Uplink Packet Access (HSUPA).

[0141] In one embodiment, the base station 114a and the RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b of the base station 114a and the WTRUs 102a, 102b, 102c, or the RANs 103b / 104b / 105b, and the WTRUs 102c, 102d may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using Long Term Evolution (LTE) or LTE-Advanced (LTE-A). In the future, the air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and V2X technologies and interfaces (e.g., sidelink communications), as well as 3GPP NR technologies including NR V2X technologies and interfaces (e.g., sidelink communications).

[0142] The base station 114a of the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g, or the RRHs 118a, 118b, TRPs 119a, 119b, or the RSUs 120a, 120b, and the WTRUs 102c, 102d, 102e, and 102f of the RAN 103b / 104b / 105b may be configured to communicate with the IEEE 802.16 (e.g., (Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), and other standards. IEEE 802.11b may implement radio technologies such as GSM (Global System for Mobile Communications), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0143] To implement the methods, systems, and devices for redundant transmission in wireless networks as disclosed herein, the base station 114c of FIG. 10A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as an office, a home, a vehicle, a train, an airborne, a satellite, a factory, a campus, etc. In an embodiment, the base station 114c and the WTRU 102, for example, the WTRU 102e, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another example, the base station 114c and the WTRU 102, e.g., the WTRU 102e, may establish a picocell or a femtocell utilizing a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.). As shown in FIG 10A, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0144] The RAN 103 / 104 / 105 or RAN 103b / 104b / 105b may communicate with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authentication and authorization, application, or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., or may perform high-level security functions, such as user authentication.

[0145] Although not shown in Figure 10A, it will be understood that the RAN 103 / 104 / 105 or RAN 103b / 104b / 105b or core network 106 / 107 / 109 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 103 / 104 / 105 or RAN 103b / 104b / 105b, or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 or RAN 103b / 104b / 105b, which may utilize E-UTRA radio technology, the core network 106 / 107 / 109 may also communicate with another RAN (not shown) using GSM or NR radio technology.

[0146] The core networks 106 / 107 / 109 may also serve as gateways for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, or other networks 112. The PSTN 108 may include a public switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communications protocols such as the transmission control protocol (TCP), user datagram protocol (UDP), and internet protocol (IP) of the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communications networks owned or operated by other service providers. For example, the network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RANs 103 / 104 / 105 or RANs 103b / 104b / 105b, or a different RAT.

[0147] To implement methods, systems, and devices for redundant transmission in a wireless network as disclosed herein, some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102g shown in FIG. 10A may be configured to communicate with a base station 114a, which may use a cellular-based radio technology, and a base station 114c, which may use an IEEE 802 radio technology.

[0148] Although not shown in FIG. 10A, it will be appreciated that the user equipment may have a wired connection to a gateway. The gateway may be a Residential Gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. It will be appreciated that much of the subject matter contained herein may apply equally to UEs that are WTRUs and UEs that use a wired connection to connect to a network. For example, subject matter applied to wireless interfaces 115, 116, 117, and 115c / 116c / 117c may apply equally to a wired connection.

[0149] FIG. 10B is a system diagram of an example RAN 103 and core network 106 that may implement methods, systems, and devices for redundant transmission in a wireless network as disclosed herein. As described above, the RAN 103 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 115 using UTRA radio technology. The RAN 103 may also communicate with the core network 106. As shown in FIG. 10B, the RAN 103 may include Node Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node Bs and Radio Network Controllers (RNCs).

[0150] As shown in FIG. 10B, Node Bs 140a, 140b may communicate with RNC 142a. Additionally, Node B 140c may communicate with RNC 142b. Node Bs 140a, 140b, and 140c may communicate with their respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b may communicate with each other via an Iur interface. Each of RNCs 142a and 142b may be configured to control the respective Node Bs 140a, 140b, and 140c to which it is connected. Additionally, each of RNCs 142a and 142b may be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0151] The core network 106 shown in Figure 10B may include a media gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing elements is illustrated as part of the core network 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0152] The RNC 142a in the RAN 103 may be connected to an MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices.

[0153] The RNC 142a in the RAN 103 may also be connected to an SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to a GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0154] The core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0155] 10C is a system diagram of an example RAN 104 and core network 107 that may implement methods, systems, and devices for redundant transmission in a wireless network as disclosed herein. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the core network 107.

[0156] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO techniques. Thus, the eNode-B 160a may transmit wireless signals to, and receive wireless signals from, the WTRU 102a, for example, using multiple antennas.

[0157] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. on the uplink or downlink. As shown in FIG 10C, the eNode-Bs 160a, 160b, and 160c may communicate with one another over an X2 interface.

[0158] The core network 107 shown in Figure 10C may include a Mobility Management Gateway (MME) 162, a Serving Gateway 164, and a Packet Data Network (PDN) Gateway 166. Although each of the foregoing elements is illustrated as part of the core network 107, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0159] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, and 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0160] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing the context of the WTRUs 102a, 102b, and 102c, etc.

[0161] The serving gateway 164 may also be connected to a PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0162] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional landline communications devices. For example, the core network 107 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned or operated by other service providers.

[0163] 10D is a system diagram of an example RAN 105 and core network 109 that may implement methods, systems, and devices for redundant transmission in a wireless network as disclosed herein. The RAN 105 may communicate with the WTRUs 102a and 102b over an air interface 117 using an NR radio technology. The RAN 105 may also communicate with the core network 109. A Non-3GPP Interworking Function (N3IWF) 199 may communicate with the WTRU 102c over an air interface 198 using a non-3GPP radio technology. The N3IWF 199 may also communicate with the core network 109.

[0164] The RAN 105 may include gNode-Bs 180a and 180b. It will be appreciated that the RAN 105 may include any number of gNode-Bs. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When an integrated access and backhaul connection is used, the same air interface may be used between the WTRUs and the gNode-Bs, which may be the core network 109 via one or more gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, or digital beamforming techniques. Thus, the gNode-B 180a may transmit wireless signals to and receive wireless signals from the WTRU 102a, for example, using multiple antennas. It will be appreciated that the RAN 105 may use other types of base stations, such as eNode-Bs. It should also be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may use eNode-Bs and gNode-Bs.

[0165] The N3IWF 199 may include a non-3GPP access point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using an 802.11 protocol.

[0166] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. on the uplink or downlink. As shown in FIG. 10D, the gNode-Bs 180a and 180b may communicate with one another, for example, over an Xn interface.

[0167] The core network 109 shown in FIG. 10D may be a 5G core network (5GC). The core network 109 may provide multiple communication services to customers interconnected by a radio access network. The core network 109 includes several entities that perform the functionality of a core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of a core network. It is understood that such a core network entity may be a device configured for wireless or network communication, or a logical entity implemented in the form of computer-executable instructions (software) stored in a memory of, and executed by, a processor of a computer system, such as the system 90 shown in FIG. 10G.

[0168] In the example of Figure 10D, the 5G core network 109 may include an access and mobility management function (AMF) 172, a Session Management Function (SMF) 174, a User Plane Function (UPF) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, and a User Data Repository (UDR) 178. Although each of the foregoing elements is illustrated as part of the 5G core network 109, it will be understood that any of these elements may be owned or operated by an entity other than the core network operator. It will also be understood that a 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Although Figure 10D shows the network functions connecting directly to each other, it will be understood that they may communicate through a routing agent, such as a diameter routing agent or a message bus.

[0169] In the example of Figure 10D, connectivity between network functions is achieved through a set of interfaces or reference points. It will be appreciated that network functions may be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. Invocation of network function services may be achieved through direct connections between network functions, messaging exchanges on a message bus, software function invocations, etc.

[0170] The AMF 172 may be connected to the RAN 105 via an N2 interface and may function as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to and from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in FIG. 10D.

[0171] The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may function as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

[0172] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be an Ethernet network or any type of network that exchanges packets of data. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting the packet data network with an N6 interface or by connecting to each other or other UPFs via an N9 interface. In addition to providing access to the packet data network, the UPF 176 may be responsible for packet routing and forwarding, enforcement of policy rules, quality of service handling for user plane traffic, and downlink packet buffering.

[0173] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via an air interface technology not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0174] The PCF 184 may be connected to the SMF 174 via an N7 interface, to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in FIG. 10D. The PCF 184 may provide policy rules to control plane nodes, such as the AMF 172 and the SMF 174, allowing the control plane nodes to enforce these rules. The PCF 184 may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c, and the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0175] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may connect to network functions that can add to, read, and modify data in the repository. For example, the UDR 178 may connect to the PCF 184 via an N36 interface. Similarly, the UDR 178 may connect to the NEF 196 via an N37 interface, and the UDR 178 may connect to the UDM 197 via an N35 interface.

[0176] The UDM 197 may act as an interface between the UDR 178 and other network functions. The UDM 197 may authorize the network functions for access of the UDR 178. For example, the UDM 197 may connect to the AMF 172 via an N8 interface, and the UDM 197 may connect to the SMF 174 via an N10 interface. Similarly, the UDM 197 may connect to the AUSF 190 via an N13 interface. The UDR 178 and the UDM 197 may be tightly integrated.

[0177] The AUSF 190 performs authentication related operations and connects to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0178] The NEF 196 exposes capabilities and services in the 5G core network 109 to an Application Function (AF) 188. The exposure may occur over an N33 API interface. The NEF may connect to the AF 188 via the N33 interface and may connect to other network functions to expose capabilities and services of the 5G core network 109.

[0179] The application functions 188 may interact with network functions in the 5G core network 109. The interaction between the application functions 188 and the network functions may be via a direct interface or may occur via the NEF 196. The application functions 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by companies that have business relationships with the mobile network operators.

[0180] Network slicing is a mechanism that mobile network operators can use to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing allows operators to create customized networks to provide optimized solutions for different market scenarios that require diverse requirements, for example in the areas of functionality, performance, and isolation.

[0181] 3GPP is designing the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that have very diverse and sometimes extreme requirements. Without the use of network slicing technology, the network architecture is likely not flexible and scalable enough to efficiently support a wider range of use cases, which is necessary when each use case has its own specific set of performance, scalability, and availability requirements. In addition, it should make the introduction of new network services more efficient.

[0182] Referring again to FIG. 10D, in a network slicing scenario, the WTRU 102a, 102b, or 102c may connect to the AMF 172 via an N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

[0183] The core network 109 may facilitate communication with other networks. For example, the core network 109 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server that serves as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include or communicate with a short message service (SMS) service center that facilitates communication via short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and the server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned or operated by other service providers.

[0184] The core network entities described herein and shown in Figures 10A, 10C, 10D, or 10E are identified by the names given to those entities in certain existing 3GPP specifications, although it is understood that future such entities and functions may be identified by other names and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, it is understood that the specific network entities and functions described and shown in Figures 10A, 10B, 10C, 10D, or 10E are provided by way of example only, and that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communications system, whether currently defined or defined in the future.

[0185] 10E illustrates an example communication system 111 in which the systems, methods, and apparatus described herein for implementing redundant transmission in a wireless network may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base stations gNBs, V2X networks, or other network elements. One or more, or all, of WTRUs A, B, C, D, E, and F may be outside the coverage 131 of an access network. WTRUs A, B, and C form a V2X group, where WTRU A is the group lead and WTRUs B and C are group members.

[0186] WTRUs A, B, C, D, E, and F may communicate with each other over Uu interface 129 via gNB 121 when they are within the coverage of the access network 131. In the example of FIG. 10E, WTRUs B and F are shown within the coverage of the access network 131. WTRUs A, B, C, D, E, and F may communicate with each other directly over a sidelink interface (e.g., PC5 or NR PC5), such as interface 125a, 125b, or 128, regardless of whether they are under or outside the coverage of the access network 131. For example, in the example of FIG. 10E, WRTU D, which is outside the coverage of the access network 131, communicates with WTRU F, which is within the coverage 131.

[0187] WTRUs A, B, C, D, E, and F may communicate with RSUs 123a or 123b via a vehicle-to-network communications (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate to a V2X server 124 via a vehicle-to-infrastructure communications (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate to another UE via a vehicle-to-person communications (V2P) interface 128.

[0188] FIG 10F is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communication and operation with systems, methods, and apparatus implementing redundant transmission in a wireless network described herein, such as the WTRU 102 (e.g., UE) of FIG 10A, FIG 10B, FIG 10C, FIG 10D, or FIG 10E, or FIG 1-9. As shown in FIG 10F, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements. Also, the base stations 114a and 114b, or the base stations 114a and 114b, may represent, but are not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a home Node B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, a next generation node B (gNode-B), and a proxy node, among others, and may include some or all of the elements illustrated in FIG. 10F and may be example implementations performing the disclosed systems and methods for redundant transmission in a wireless network (e.g., 5G) described herein.

[0189] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 10F depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0190] The transmit / receive element 122 of the UE may be configured to transmit or receive signals to or from a base station (e.g., base station 114a of FIG. 10A) via the air interface 115 / 116 / 117, or to transmit or receive signals to or from another UE via the air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit or receive RF signals. The transmit / receive element 122 may be an emitter / detector configured to transmit or receive IR, UV, or visible light signals, for example. The transmit / receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit or receive any combination of wireless or wired signals.

[0191] 10F as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Thus, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interfaces 115 / 116 / 117.

[0192] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, e.g., NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0193] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may be a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) card, a hard disk, a hard disk drive ... The processor 118 may include a storage device, such as a USB (SSD) memory card, a USB (SIM card), ...Disclosed herein are messages and procedures for redundant transmission in wireless networks that may be extended to provide an interface / API for a user via an input source (e.g., speaker / microphone 124, keypad 126, or display / touchpad / indicator 128) to request resources and request, configure, or query redundant transmission in wireless network related information, among other things, that may be displayed on the display 128.

[0194] The processor 118 may receive power from the power source 134 and may be configured to distribute or control the power to other components within the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0195] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117, or may determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable position determination method.

[0196] The processor 118 may further be coupled to other peripherals 138 and may include one or more software or hardware modules that provide additional features, functionality, or wired or wireless connectivity. For example, the peripherals 138 may include various sensors, such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnection interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, and the like.

[0197] The WTRU 102 may be included in other apparatus or devices, such as a sensor, a household appliance, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The WTRU 102 may be connected to other components, modules, or systems of such an apparatus or device via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripherals 138.

[0198] FIG. 10G is a block diagram of an exemplary computing system 90 in which one or more devices of the communications networks shown in FIGS. 10A, 10C, 10D, and 10E, such as the systems and methods shown in FIGS. 1-9 as described and claimed herein, such as particular nodes or functional entities within the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112, or the network services 113, and redundant transmission in wireless networks may be embodied. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software or any means by which such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to perform operations. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal coding, data processing, power control, input / output processing, or any other function that enables the computing system 90 to operate in a communication network. The coprocessor 81 is an optional processor that is different from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein for redundant transmission in a wireless network (e.g., 5G), such as receiving or transmitting redundant messages.

[0199] In operation, the processor 91 fetches, decodes, and executes instructions and transmits information to other resources via the computing system's main data transfer path, the system bus 80. Such a system bus connects components within the computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and operating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0200] The memories coupled to the system bus 80 include a random access memory (RAM) 82 and a read only memory (ROM) 93. Such memories include circuits that allow information to be stored and retrieved. The ROM 93 generally includes stored data that cannot be easily modified. Data stored in the RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 or the ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts virtual addresses to physical addresses when instructions are executed. The memory controller 92 can also provide a memory protection function that separates processes in the system and separates system processes from user processes. Thus, a program running in the first mode can only access memory mapped by its own process virtual address space and cannot access memory in another process' virtual address space unless memory sharing between processes is set up.

[0201] Additionally, computing system 90 may include a peripheral controller 83 that serves to communicate instructions from processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0202] The display 86, controlled by the display controller 96, is used to display visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 contains the electronic components necessary to generate the video signal that is sent to the display 86.

[0203] Additionally, computing system 90 may include communications circuitry, such as, for example, a wireless or wired network adapter 97, that may be used to connect computing system 90 to external communications networks or devices, such as the RAN 103 / 104 / 105 of Figure 10A, Figure 10B, Figure 10C, Figure 10D, or Figure 10E, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, the WTRU 102, or other networks 112, allowing computing system 90 to communicate with other nodes or functional entities of those networks. The communications circuitry may be used alone or in combination with the processor 91 to perform the transmitting and receiving steps of particular apparatus, nodes, or functional entities described herein.

[0204] It is understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which instructions, when executed by a processor, such as processor 118 or 91, cause the processor to perform or implement the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions executed on a processor of a device or computing system configured for wireless or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media for storing information, implemented in any non-transitory (e.g., tangible or physical) method or technology, although such computer-readable storage media do not include signals. Computer readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computing system.

[0205] In describing the preferred method, system, or apparatus of the disclosed subject matter (redundant transmission in wireless networks), as illustrated in the figures, specific terminology is used for clarity, however, it is not intended that the claimed subject matter be limited to the specific terminology so selected.

[0206] The various techniques described herein may be implemented in connection with hardware, firmware, software, or combinations thereof, as appropriate. Such hardware, firmware, and software may reside in apparatus located at various nodes of a communications network. The apparatus may operate alone or in combination with each other to implement the methods described herein. As used herein, terms such as "apparatus," "network apparatus," "node," "device," "network node," and the like may be used interchangeably. In addition, the use of the word "or" is generally used inclusively unless otherwise specified herein.

[0207] This specification uses examples for the disclosed subject matter, including the best mode, and also enables one of ordinary skill in the art to practice the disclosed subject matter, including making and using any device or system, and performing any incorporated methods. The disclosed subject matter may include other examples that occur to one of ordinary skill in the art (e.g., skipping steps, combining steps, or adding steps between the example methods disclosed herein).

[0208] Among other things, the methods, systems, and devices described herein may provide redundant transmission in a 5G network. The method, system, computer-readable storage medium, or device may provide for triggering a PDU session modification process to trigger a redundant transmission stop, sending an N2 SM message to SMF1 to request a modification of PDU session 1, and forwarding the PDU session modification message to SMF1. These steps may be performed by a user equipment (UE) or a radio access network (RAN) node. The method, system, computer-readable storage medium, or apparatus includes receiving configuration information for allocating Packet Data Unit (PDU) Session Pair Information (PSPI) to one or more PDU sessions, determining using the configuration information that a first PDU session and a second PDU session are associated, associating the first PSPI with the first PDU session and the second PDU session based on the configuration, transmitting the PSPI to a network in a first PDU session establishment message to establish the first PDU session, and transmitting the PSPI to the network in a second PDU session establishment message to establish the second PDU session. The first PDU session and the second PDU session may be associated with a Data Network Name (DNN) or a single network. The method, system, computer-readable storage medium, or apparatus may be associated with different combinations of a packet data unit (PDU) session pair information (PSPI) for a first PDU session from a UE in a PDU session establishment request message, and notifying a RAN node that the first PDU session is associated with a second PDU session, wherein notifying the RAN node that the first PDU session is associated with the second PDU session is performed by sending the PSPI to an AMF, which forwards the PSPI to the RAN node in an N2 message. All combinations in this paragraph (including removal or addition of steps) are contemplated to be consistent with other parts of the detailed description.

Claims

1. A user equipment, A processor; a memory coupled to the processor, the memory including executable instructions stored in the memory, the instructions, when executed by the processor, causing the processor to: receiving configuration information for allocating Packet Data Unit (PDU) Session Pair Information (PSPI) to one or more PDU sessions; Using the configuration information to determine that a first PDU session and a second PDU session are associated; Associating the first PSPI with the first PDU session and the second PDU session based on the configuration; Sending the PSPI in a first PDU session establishment message to a network to establish the first PDU session; and causing the network to transmit the PSPI in a second PDU session establishment message to establish the second PDU session.

2. The user equipment of claim 1 , wherein the configuration information is received in a User Equipment Route Selection Policy (URSP) rule.

3. The user equipment of claim 1 , wherein the configuration information is received in an AT command.

4. The operation, determining, by a higher layer, the PSPI; The user equipment of claim 1 , further comprising: providing the PSPI to the user equipment via an AT command.

5. The user equipment of claim 1 , wherein the PSPI is a number.

6. 2. The user equipment of claim 1, wherein the first PDU session and the second PDU session are associated with redundant transmission.

7. 2. The user equipment of claim 1, wherein the first PDU session and the second PDU session are associated with dual connectivity redundant transmission.

8. 2. The user equipment of claim 1, wherein the first PDU session and the second PDU session are associated with different combinations of a data network name (DNN) and a single network slice selection assistance information (S-NSSAI).

9. The user equipment of claim 1 , wherein the configuration information is received in a User Equipment Route Selection Policy (URSP) rule, the URSP rule including a redundant transmission indicator.

10. 2. The user equipment of claim 1, wherein the configuration information is received in a User Equipment Route Selection Policy (URSP) rule, the URSP rule including a redundant transmission indicator, the redundant transmission indicator being part of a route selection descriptor in the URSP rule.

11. 1. A method comprising: receiving configuration information for allocating Packet Data Unit (PDU) Session Pair Information (PSPI) to one or more PDU sessions; Using the configuration information to determine that a first PDU session and a second PDU session are associated; Associating the first PSPI with the first PDU session and the second PDU session based on the configuration; Sending the PSPI in a first PDU session establishment message to a network to establish the first PDU session; and sending the PSPI in a second PDU session establishment message to the network to establish the second PDU session.

12. The method of claim 11 , wherein the configuration information is received in a User Equipment Routing Policy (URSP) rule.

13. The method of claim 11 , wherein the configuration information is received in an AT command.

14. The operation, determining, by a higher layer, the PSPI; The method of claim 11 , further comprising: providing the PSPI to the user equipment via an AT command.

15. The method of claim 11 , wherein the PSPI is a number.

16. 12. The method of claim 11, wherein the first PDU session and the second PDU session are associated with redundant transmission.

17. 12. The method of claim 11, wherein the first PDU session and the second PDU session are associated with dual connectivity redundant transmission.

18. 12. The method of claim 11, wherein the first PDU session and the second PDU session are associated with different combinations of a data network name (DNN) and a single network slice selection assistance information (S-NSSAI).

19. An apparatus comprising: A processor; a memory coupled to the processor, the memory including executable instructions stored in the memory, the instructions, when executed by the processor, causing the processor to: receiving a Packet Data Unit (PDU) Session Pair Information (PSPI) for a first PDU session from the UE in a PDU Session Establishment Request message; Informing a RAN node that the first PDU session is associated with a second PDU session; Informing the RAN node that the first PDU session is associated with the second PDU session is performed by sending the PSPI to an Access and Mobility Management Function (AMF), which forwards the PSPI to the RAN node in an N2 message.

20. The apparatus of claim 20, wherein the apparatus executes a Session Management Function (SMF).

Images