Enhanced redundant transmission in 5G networks

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 on November 25, 2020, entitled "Enhancement To Redundant Transmission In 5G Network", the content of which is incorporated herein by reference.

Background Art

[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 technology (New RAT), which is expected to include the provision of new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new non-backward compatible radio access in new spectrums below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with branching requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectra, for example, providing opportunities for ultra-mobile broadband access for indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, utilizing centimeter-wave and millimeter-wave specific design optimizations.

[0003] This background information is provided to clarify information that the applicant considers potentially relevant. It is not necessarily intended, nor should it be interpreted, to acknowledge that any of the prior information constitutes prior art. [Overview of the Initiative]

[0004] This specification discloses methods, systems, and devices relating to redundant transmission, PDU session establishment or modification processes, or URSP enhancement for UL traffic replication at the PDU layer for URLLC applications. In particular, several issues related to existing mechanisms that enable and support the redundant transmissions expressed herein are addressed. The disclosed subject matter may enhance redundant transmission mechanisms.

[0005] This specification discloses the provision of policies and parameters to the network for supporting redundant transmission configurations. How RSN and redundant user plane requirements are linked, as well as a list of parameters and policy rules provided from the PCF to the SMF for redundant transmission determination and configuration, are described in more detail. The AF may also provide input to the PCF, which may influence the parameters and policy rules.

[0006] This specification discloses a procedure by which a UE provides PDU session pair information to the core network so that PDU session pair information can be provided to RAN nodes 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 RAN nodes, and how the UE may determine to make PDU sessions redundant based on instructions from the application layer are described in more detail.

[0007] This specification discloses a method for modifying PDU sessions for redundant transmission. Possible triggers in different network entities (UE, RAN nodes, AF, and SMF), and procedures for continuing redundant transmission by disabling or stopping redundant transmission, or by replacing one of the PDU sessions in a session pair, are described in more detail.

[0008] This specification discloses enhancements to URSP rules to enable the UE to perform traffic replication and elimination at the PDU layer. The subject of the UE being able to determine whether to utilize redundancy, and that this determination being made independently of the application layer, is explained in more detail.

[0009] For example, the method may include receiving configuration information for assigning 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 and second PDU sessions based on the configuration; sending the PSPI to the network in a first PDU session establishment message to establish the first PDU session; and sending the PSPI to the network 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 is further described below in “Modes for Carrying Out the Invention.” This summary is not intended to identify any major or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to the limitations that resolve any or all of the defects described in any part of this disclosure. [Brief explanation of the drawing]

[0011] A more detailed understanding can be obtained from the following detailed explanation, which is provided in conjunction with the attached diagrams as examples. [Figure 1] This illustrates an exemplary 5G system service-based architecture. [Figure 2]This shows an exemplary non-roaming 5G system architecture in reference point representation. [Figure 3] An exemplary user-plane protocol stack is shown. [Figure 4] This illustrates an exemplary scenario for an end-to-end redundant user plane path using dual connectivity. [Figure 5] This demonstrates exemplary redundant transmission with two N3 tunnels between the PSA UPF and a single NG-RAN node. [Figure 6] This document provides an example procedure for PSPI generation and provisioning. [Figure 7A] This document provides an example procedure for updating the PSPI due to a PDU session change / release. [Figure 7B] This document provides an example procedure for updating the PSPI due to a PDU session change / release. [Figure 8] This document presents an exemplary procedure for redundant transmission in a 5G network. [Figure 9] This document illustrates an exemplary user interface for configuring redundant transmission, where displays can be generated based on methods, systems, and devices for redundant transmission in a wireless network. [Figure 10A] An example communication system is shown. [Figure 10B] An exemplary system including the RAN and core network is shown. [Figure 10C] An exemplary system including the RAN and core network is shown. [Figure 10D] An exemplary system including the RAN and core network is shown. [Figure 10E] Another exemplary communication system is shown. [Figure 10F] This is a block diagram of an exemplary device or apparatus, such as a WTRU. [Figure 10G] This is a block diagram of an exemplary computing system. [Modes for carrying out the invention]

[0012] 5G Network Architecture Figure 1 illustrates a 5G system with an exemplary non-roaming reference architecture having service-based interfaces within the control plane.

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

[0014] End-to-end communication between an application within the UE and an application within an external network uses services provided by the 3GPP system and optionally services provided by a Services Capability Server (SCS) resident within the DN.

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

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

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

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

[0019] Figure 3 shows the protocol stack for user plane transport related to the PDU session.

[0020] Redundant PDU session Redundant transmission for highly reliable communication is specified in TS23.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 must establish the PDU session as an always-on PDU session. An always-on PDU session is a PDU session in which user plane resources must be activated during each transition from CM-IDLE mode to CM-CONNECTED state. Based on instructions from higher layers, the UE may request that a PDU session be established as an always-on PDU session. The SMF determines whether a PDU session can be established as an always-on PDU session. There are three options specified in TS23.501 to support URLLC highly 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 can provide 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 a single NG-RAN node (for redundant transmission over the N3 / N9 interface). In all cases, a single N1 interface to the AMF exists.

[0022] Dual connectivity based on end-to-end redundant user plane paths Figure 4 shows an exemplary user plane resource configuration for a dual PDU session when redundancy is applied. The UE may configure two redundant PDU sessions on the 5G network so that 5GS sets up user plane paths for the two redundant PDU sessions to be isolated. The UE's subscription indicates whether the UE is permitted to have redundant PDU sessions, and this instruction is provided from the UDM to the SMF. One PDU session extends from the UE to UPF1, which acts as a PDU session anchor, via the master NG-RAN, and the other PDU session extends from the UE to UPF2, which acts as a PDU session anchor, via the secondary NG-RAN.

[0023] Based on these two PDU sessions, two independent user plane paths are established. Traffic via UPF1 and UPF2 can be routed to the DN through 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, providing different combinations of DNN and S-NSSAI for each PDU session. The SMF determines whether to process the 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. Furthermore, the SMF determines the Redundant Sequence Number (RSN) that distinguishes the PDU sessions to be processed redundantly. PDU sessions associated with different RSN values ​​will be implemented by different redundant UP resources. The RSN indicates in the NG-RAN that redundant user plane resources will be provided for a given PDU session by dual connectivity. The request for redundant processing is made by indicating the RSN in the NG-RAN at a session-level granularity. The value of the RSN parameter indicates the redundant user plane requirement for the PDU session.

[0025] Replicated traffic from an application associated with a redundant PDU session is distinguished by two separate traffic descriptors, each within a separate URSP rule. These traffic descriptors must have different DNNs, IP descriptors, or non-IP descriptors (e.g., MAC address, VLAN ID) so that the two redundant PDU sessions match the RSD of the separate URSP rules. How the replication path is utilized end-to-end for redundant traffic distribution is outside the scope of 3GPP. It is possible to manage the replication and elimination of redundant packets / frames on the replication path, which can span both 3GPP segments and potentially fixed network segments, by relying on higher-layer protocols such as IEEE TSN (Time Sensitive Networking) or FRER (Frame Replication and Elimination for Reliability). In other words, the higher layer is responsible for the replication and elimination of traffic in this scenario.

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

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

[0028] To ensure that the two N3 tunnels are forwarded via separate transport layer paths, the SMF or PSA UPF must provide different routing information (e.g., different IP addresses or different network instances) in the tunnel information, and this routing information must be mapped to separate transport layer paths according to the network deployment configuration. Accordingly, the SMF indicates to the NG-RAN and PSA UPF that one of the two CN / AN tunnel entries will be 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 the QoS flow received by the PSA UPF from the DN, the PSA UPF duplicates the packet and assigns them the same GTP-U sequence number for redundant transmission. The NG-RAN discards the duplicate packets based on the GTP-U sequence number and then forwards the PDU to the UE.

[0030] For each uplink packet in the QoS flow received by the NG-RAN from the UE, the NG-RAN duplicates the packet and assigns them the same GTP-U sequence number for redundant transmission. These packets are then transmitted separately to the PSA UPF via two N3 tunnels. Accordingly, the PSA UPF removes duplicate packets based on their GTP-U sequence numbers.

[0031] Support for redundant transmission at the transport layer Redundant transmission can be supported within 5G systems without making any assumptions regarding the support of protocols such as IEEE FRER at the application layer (DN only), and simultaneously without requiring redundant GTP-U tunnels via N3. The backhaul provides two separate transport paths between the UPF and NG-RAN. Redundancy functions within the NG-RAN and UPF utilize independent paths at the transport layer. Support for redundant transmission at the transport layer does not require the influence of 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 at the transport layer, and other factors described in Section 6.3.3, the SMF selects a UPF that supports redundant transmission at the transport layer for the PDU session. One N3 GTP-U tunnel is established between the UPF and the NG-RAN.

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

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

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

[0036] System enhancements for redundant PDU sessions Regarding the existing redundant PDU session mechanism specified in TS23.501, several possible enhancements have been identified. Specifically, the 3GPP SA2 Working Group has listed several potential objectives for further enhancing the current redundant PDU session mechanism, as outlined in SP-200448:TEI17_SE_RPS-New WID:System enhancement for redundant PDU Session, as follows:

[0037] With respect to the first objective, it is disclosed that if the UE has knowledge of PDU session pair information for redundant PDU sessions, the UE may provide the PDU session pair information to the SMF(s)

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

[0039] Regarding the third objective, it is necessary to clarify how the UE acquires knowledge of PDU session pair information for redundant PDU sessions.

[0040] Consideration Redundant PDU sessions were defined to support highly 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, allowing network functions and RAN nodes to know that a PDU session is redundant and allocate user plane resources for that PDU session accordingly. In addition, the RSN is determined by the SMF and 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 several unresolved issues, such as the following.

[0041] Regarding the first issue, there is no definition for how to assign RSN values ​​to indicate redundant user plane requirements. In fact, the meaning of redundant user plane requirements is not defined. The current specification does not provide a mechanism for defining redundant user plane requirements and whether they should be associated with specific standardized attributes such as QoS requirements / parameters.

[0042] Regarding the second issue, TS23.501 states that the SMF determines whether to handle PDU sessions redundantly based on policies provided by the PCF. However, current network designs have 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., the PCF) could be used to help guide the SMF in making this determination. Overall system performance can be improved if the SMF determines the RSN value based on local configuration and assigns RSNs so that the RAN can use the RSNs to determine which PDU sessions are linked.

[0043] Regarding the third issue, RSN can only indicate that PDU sessions are handled redundantly using specific redundant user plane requirements. 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, network functions and RAN nodes 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 issue, in order to provide PDU session pair information (PSPI) to RAN nodes, the network needs to possess such information. However, there is no defined mechanism for how the network (e.g., an SMF) can obtain this information. Since the two sessions are managed independently, it is likely that two separate SMFs will manage the two PDU sessions. It cannot be assumed that these two SMFs are able to communicate with each other. There is no existing mechanism that would allow these two SMFs to exchange such session management information. In fact, each SMF is unaware that another redundant PDU session has been established.

[0045] Regarding the fifth issue, the method for providing PDU session pair information to other network entities (e.g., RAN nodes and AFs) is not addressed. Normally, the SMF should be responsible for providing such session management-related information. However, as mentioned above, there may be cases where the SMF cannot provide such information.

[0046] Regarding the sixth issue, while only the UE can trigger 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, the mechanism by which the application server can do so is not defined. In addition, the application server may request to be notified when two redundant PDU sessions are established for application traffic. Given the fact that two different SMFs may each manage PDU sessions, it would be desirable to define some mechanisms for how the application server subscribes to which network entity for such events and how it delivers notifications to the AF or SCS / AS.

[0047] Regarding the seventh issue, another issue concerns redundant session changes. When a network / UE / application server decides to stop redundant transmission by releasing / deactivating one PDU session, and then decides to later associate the remaining PDU session with another PDU session for redundant transmission, the RAN node and anchor UPF need to be notified to adjust user plane resource allocation and traffic replication / removal behavior. This can be done primarily 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 change procedure.

[0048] Regarding the eighth issue, existing mechanisms rely on higher layers (e.g., application and transport layers) 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 would allow for more dynamic redundant transmission. For example, the UE or UPF could dynamically decide, based on network conditions, whether to send application traffic to one PDU session (i.e., no redundant transmission) or to two PDU sessions (i.e., redundant transmission). Under the current URSP mechanism, it is impossible for the UE to send the same UL traffic to two PDU sessions. Therefore, some URSP enhancement is needed to allow the UE to duplicate traffic and send it to two PDU sessions.

[0049] Considering the aforementioned issues, several new information elements and mechanisms are desired to enhance existing redundant PDU session methods.

[0050] This specification discloses redundant transmission for URLLC applications in 5GC. In particular, several issues related to existing mechanisms that enable and support the redundant transmission explicitly described 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 RSN is used only for dual connectivity (DC) based redundant transmission, the disclosed approach can be assumed to be specific to DC-based mechanisms unless explicitly mentioned for other mechanisms (i.e., N3 / N9 tunnel-based). Furthermore, PDU session pair information is also defined only for DC-based mechanisms. 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, PDU sessions established in a dual connectivity-based mechanism are managed by different SMFs (e.g., at least two), and these SMFs do not need to communicate directly with each other.

[0052] Redundant user plane requirements and RSN The following discloses the policy and parameter provisioning from the PCF / AF for redundant transmission. The RSN indicates redundant user plane requirements and can be configured in several ways. For example, it may be configured to indicate one or more specific performance metric requirements for application data transfer, such as packet loss rate or delay threshold. Thus, redundant user plane requirements can be associated with specific QoS parameters or characteristics to reflect performance metrics. The PCF provides this mapping to the SMF, which associates the RSN value with PDU sessions for redundant transmission. Redundant user plane requirements may be configured per application traffic identified by the application ID, per UE, per PDU session, per QoS flow, or per DNN / S-NSSAI.

[0053] Policy and parameter provisioning for redundant transmission The SMF requires some information to determine whether a PDU session should be a redundant PDU session, and an RSN value to indicate redundant user plane requirements. The PCF can provide these policies and parameters to the SMF. The PCF may provide the following information to the SMF so that it can make decisions regarding redundant transmissions:

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

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

[0056] Thirdly, the information may include a mapping between QoS requirements (indicated by 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 RSN values ​​to reflect redundant user plane requirements. Alternatively, the PCF may provide a mapping between the SDF and RSN values ​​or ranges of RSN values. Specifically, the PCF may set some thresholds for certain performance metrics (e.g., QoS characteristics or parameters) for the SMF so that the SMF can set RSN values.

[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 may come from reporting events / conditions that can trigger SMF to notify PCF / AF of any changes to 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 QoS in one of the redundant sessions / tunnels is not met or requires some modification, or when PDU session pair information (PSPI) is updated for any reason.

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

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

[0061] Eighth, the information may concern policies regarding how PSPIs are managed, indicating whether the UE or SMF is responsible for generating and updating PSPIs. The PCF may provide the SMF with the above information in PCC rules or PDU session-related policy information. The AF may also input some application-related information into the network (e.g., the PCF) to influence 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 within a certain location, for a certain time period, or when the UE is moving. The AF may indicate to the PCF that redundant transmission is preferred or required for a particular application (e.g., identified by an application ID, the IP address of the application server) associated with a class of QoS requirements (e.g., 5QI, maximum packet loss rate, packet delay budget) and the corresponding redundant user plane requirements. One option to do this is to enhance the procedure for the 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 transmissions that are sent to the SMF.

[0062] When an SMF receives a PDU session establishment / modification request, it determines whether redundant transmission is required based on the policy rules and information provided by the PCF. The SMF then selects a UPF that supports redundant transmission. In particular, the SMF may consider the following information for UPF selection related to redundant transmission: firstly, whether the UPF can perform traffic replication / removal to support N3 / N9-based redundant transmission; and secondly, whether the UPF has the capability to support RSN for DC-based redundant transmission.

[0063] Furthermore, the PCF provides policies and parameters to the SMF to manage redundant transmissions in a static manner, and these policies or parameters are not frequently changed or updated. On the other hand, when the SMF determines whether redundant transmissions are required or what level of redundant user plane requirements are needed, it can consult in real time with other network functions such as UDM / UDR209, AMF203, UPF206, and NWDAF regarding network status, UE subscription data, and user plane performance.

[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 to the RAN node in order to establish dual connectivity and enable redundant transmission. This specification discloses the subject of how to construct a PSPI, what information to include in the PSPI, and how to provide the PSPI to the RAN node (e.g., master RAN202).

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

[0066] Figure 6 shows an exemplary procedure for PSPI generation and provisioning to RAN nodes. It is assumed that different SMFs (e.g., at least two) are selected to manage different PDU sessions in a general manner.

[0067] Step 220: SMF204 establishes PDU session 1 and determines that redundant transmission is required. Therefore, SMF204 assigns PDU session 1 to RSN1. At this point, the RAN node knows that dual connectivity is required to support redundant transmission, but since it only has one PDU session information, the RAN node waits for another PDU session information or PSPI to establish dual connectivity.

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

[0069] Step 222: Based on the policies and parameters provided by the PCF and the operator's local policy configuration, SMF205 determines that redundant transmission is required and assigns RSN2 to PDU session ID 2. Next, SMF205 selects UPF207 as the anchor point for PDU session 2. SMF205 may also contact UDM / UDR209 to retrieve subscription data for UE201 in order to verify whether UE201 can tolerate redundant transmission. In addition, if SMF205 does not have enough information to make a decision or generate an RSN, it may contact the PCF to retrieve any policies related to redundant transmission.

[0070] Step 223: SMF205 sends an N4 session establishment or change request message to UPF207.

[0071] Step 224: Next, SMF205 sends an N2 SM message to the RAN node. The N2 SM message includes the PDU session ID 2, QoS profile, RSN 2, and the service area of ​​SMF205. The master RAN node 202 knows that PDU session 2 needs to be handled redundantly in dual connectivity because of the associated RSN. However, at this stage, even though the RAN node knows the context information of PDU session 1 during 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 acceptance message is also included and forwarded to UE201.

[0072] Step 225: The NAS SM acceptance message is forwarded to UE201 along with RSN2.

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

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

[0075] Step 227: UE201 sends PSPI information to AMF203 via NAS message. AMF203 can then send the PSPI to UDM / UDR209, where it is stored as part of the UE context. Storing the PSPI in UDM / UDR209 makes it easier for other network entities to retrieve the UE201's PSPI, especially when two different SMFs manage two separate sessions. In addition, AMF203 may send the PSPI to SMF204 or SMF205 based on operator policy configuration. In this case, the SMF may contact the UDR / UDM to store the PSPI as part of the UE context.

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

[0077] Step 229: Using PSPI, the RAN node begins operating as master RAN node 202, selects a secondary RAN node based in part on PSPI, and establishes dual connectivity for PDU session 2. Note that how the secondary RAN node is selected and dual connectivity is established is outside the scope of this specification.

[0078] Step 230: The master RAN node 202 sends an N2 SM message containing N3 tunnel information for transferring user plane data between the secondary RAN node and UPF207 to SMF205 via AMF203.

[0079] Step 231: Optionally, if AF208 or the application server has subscribed to receive notifications when redundant transmission is enabled for its traffic, SMF204 or SMF205 may send such notifications. AF208 may send a subscription request to the PCF / SMF through the AF208 Impact on Traffic Routing procedure. Alternatively, UE201 may send its notification to AF / AS208 by using application layer signals, including PSPI.

[0080] In the case of "Error! Reference not found," UE201 generates a PSPI after PDU session 2 is established. Therefore, the network is not initially aware that the PDU sessions are linked. UE201 may later decide to send a NAS message (e.g., a PDU session change message) for each of the two PDU sessions. UE201 may decide to send a NAS message based on a request for redundant transmission from the application layer (e.g., an instruction from the application layer that redundant PDU sessions are needed may come from TE to ME via an AT command). The PDU session change message contains the same PSI. Each SMF then forwards the PSI to the RAN node in an N2 message (via AMF203). In this way, the RAN node knows which two PDU sessions are linked.

[0081] Furthermore, UE201 can also generate and provide a PSPI to the network in the PDU session establishment request for each PDU session. In this scenario, first, UE201 determines that redundant transmission is necessary based on a request for redundant transmission from the application layer (for example, an instruction from the application layer that redundant PDU sessions are needed may come from TE to ME via an AT command), and then UE201 generates two PDU session IDs and a PSPI. Specifically, in this case, the NAS layer of UE201 generates the PSPI. Next, UE201 sends a PDU session establishment request to the network that includes two PDU session IDs, two sets of DNN and S-NSSAI combinations, a PSPI linking the two PDU session IDs, and an instruction that redundancy is needed. Thus, the network is initially aware that the PDU sessions are linked. The PDU session change message contains the same PSI. Next, each SMF forwards the PSI to the RAN node in an N2 message (via AMF203). In this way, the RAN node knows which two PDU sessions are linked in the PDU session establishment.

[0082] Alternatively, UE201 may only provide two PDU session IDs and an instruction that redundancy is required. Upon receiving the PDU session establishment request from UE201 along with the above information, the network (e.g., SMF or AMF203) may generate a PSPI. AMF203 may still select two different SMFs to manage each PDU session in this scenario. In another scenario, UE201 may send a PSPI and a redundancy transmission instruction during the second PDU session establishment request.

[0083] Procedure for changing PDU sessions for redundant transmission This specification discloses procedures 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, as shown below: 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 modifies the redundant PDU session pair (e.g., release / deactivate one and link the other to another PDU session) to trigger an update of the PDU session pair information (PSPI).

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

[0085] Step 240: Two PDU sessions are established for redundant transmission. Note that SMF205 and UPF207 are not shown in the diagram, but different SMF and UPF are used. PDU session 1 is used as an example for explanation.

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

[0087] Case 1: UE201 triggers the process.

[0088] Step 241A: UE201 may trigger a process based on a request from the application layer. For example, application traffic may terminate or the application traffic no longer requires redundancy. Furthermore, UE201 may trigger a process due to network conditions. For example, UE201 may want to change PDU session 1 or release PDU session 1 and then associate PDU session 2 with another session for redundant transmission. This may be because UE201 has moved outside the SMF204 service area or because PDU session 1 no longer meets the requirements of the application traffic.

[0089] Step 241B: As a result, UE201 sends a PDU session change or release request message to SMF204. UE201 provides the PSPI, the ID of PDU session 1, and the combination of DNN and S-NSSAI. UE201 may provide instructions indicating whether it wishes to stop redundant transmission or continue redundant transmission by changing PDU session 1 or by replacing PDU session 1 with another session for redundant transmission. If UE201 wishes to link PDU session 2 with another PDU session, the PSPI is updated by UE201 to link PDU session 2 with the other PDU session. If it is a new PDU session, UE201 generates and provides a new PDU session ID and requests the session establishment process accordingly.

[0090] Case 2: A RAN node triggers a process.

[0091] Step 242A: While the RAN node cannot directly determine whether to stop or disable redundant transmission, it can trigger a PDU session change process that triggers the termination of redundant transmission. For example, this could be due to a handover required for the UE, unsatisfactory QoS for PDU session 1, or a radio link failure. In these cases, the RAN triggers a PDU session change process to update the redundant transmission operation, which further triggers a PSPI update. The RAN node does not generate or update the PSPI; the UE201 or SMF may perform PSPI generation or updating.

[0092] Step 242B: Master RAN node 202 sends an N2 SM message to SMF 204 requesting a change to PDU session 1. The message includes the ID of PDU session 1, the PSPI, and the reason for the PDU session change request. The reason for the PDU session change can help SMF determine whether to stop or continue redundant transmission by changing PDU session 1 or by replacing PDU session 1 with another PDU session.

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

[0094] Case 3: AF208 or the application server triggers the process.

[0095] Step 243A: AF208 can be triggered by several possible events. For example, AF208 may terminate application traffic that requires redundant transmission, or the application traffic may have reduced QoS requirements and therefore does not require redundant transmission.

[0096] Step 243B: AF208 sends a request to the PCF informing the SMF to deactivate or stop 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., whether to release or modify the PDU session. In addition, 5GC may trigger an application to start in UE201, indicating that redundant transmission is required based on a request from AF208 or the application server, and UE201 then triggers redundant transmission for application traffic by requesting to establish a PDU session to a specific DNN with S-NSSAI.

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

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

[0099] Step 245: SMF204 sends an N4 session change or release request to UPF206, depending on whether SMF decides to change PDU session 1 or release the session.

[0100] Step 246: If the SMF did not receive a PSPI in the previous step, i.e., the UE, RAN node, or AF208 does not provide a 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 creating and updating the PSPI, the SMF updates the PSPI. For example, if redundant transmission is stopped / disabled, the SMF may delete the PSPI. If PDU session 1 is replaced by another session to continue redundant transmission, the SMF may update the PDU session IDs linked together in the PSPI. If UE201 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 AMF 203, along with a change / release notification for PDU session 1 and an instruction on whether redundant transmission should be disabled. If redundant transmission attempts to continue with another PDU session replacing PDU session 1, the SMF provides a new PSPI linking the new PDU session and 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 change notification or a response, depending on which entity triggers the process first. The NAS message may include an updated PSPI if the SMF updates the PSPI.

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

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

[0105] Step 251: If UE201 is responsible for managing the PSPI, UE201 sends an updated PSPI or PSPI deletion notification to SMF via 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 deletion notification to the master RAN node 202 so that the RAN node can coordinate 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. This is optional and depends on whether AF208 is participating in the PSPI update or deletion, or configuration by the PCF.

[0109] URSP enhancements to enable UL traffic replication at the PDU layer. This specification describes how UE201 may determine to provide PSPI based on a request from the application layer (for example, based on an AT command). Alternatively, UE201 may be configured to detect when certain application layer traffic should be replicated across multiple PDU sessions, and UE201 may perform traffic replication at the PDU layer. When UE201 detects that certain application layer traffic should be replicated across multiple PDU sessions, UE201 may use the previously described procedure to establish redundant PDU sessions.

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

[0111] UE201 may use the RSD associated with the URSP rule to establish two PDU sessions for the associated traffic. UE201 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 contain multiple sets of RSDs (one for each PDU session). If UE201 can only establish one PDU session and cannot establish a second, UE201 may behave to continue with only the single PDU session. Alternatively, if the establishment of only one PDU session is successful, UE201 may terminate the first PDU session and indicate to the application that the PDU session establishment was unsuccessful (or attempt a lower priority URSP rule). Whether UE201 continues with only one PDU session or multiple PDU sessions may depend on the UE201 implementation or on the instructions in the URSP rule.

[0112] If the URSP rule indicates that N3 / N9 replication is required, UE201 may indicate to the SMF that N3 / N9 replication is required for the PDU session. Specifically, it is disclosed that two new parameters are added to the traffic descriptor of the URSP rule.

[0113] The first parameter, the redundant transmission indicator: This indicator shows whether redundant transmission is required for the traffic. If this instruction is included, an indicative instruction may be used to indicate whether traffic can be sent through a single PDU session if only one PDU session is successfully established.

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

[0115] These two attributes or indicators within the URSP rule can help UE201 determine that redundant transmission is required for specific traffic and include instructions in the PDU session establishment request message.

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

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

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

[0119] Figure 8 shows an exemplary procedure for redundant transmission in a 5G network. In step 261, UE201 may receive configuration information for assigning 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. The upper layer may determine the PSPI and provide it to UE201 via an 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, configuration information can be used to determine whether the first PDU session and the second PDU session are associated. PDU sessions may be considered associated if both PDU sessions are used to send data from the same application (for example, if the application sends the same data through both PDU sessions to achieve redundancy), or if both PDU sessions are used to receive data for the same application (for example, if the same application data is received through both PDU sessions (for example, if the application data is duplicated to achieve redundancy)).

[0121] In step 263, configuration information can be used to determine whether 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., SMF204) with a first PDU session establishment message to establish a first PDU session.

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

[0124] Parameters involved in redundant transmission operation can be provisioned by an end user (e.g., UE201), network operator, or application service provider through a user interface. The user interface may be implemented to configure or program these parameters using default values, and to enable or disable redundant transmission. An exemplary user interface is shown in Figure 9. The progress of any of the steps considered herein (e.g., a transmitted message or the success of a step) may be displayed. In addition, graphical output may be displayed on the display interface in Figure 9. The graphical output may include the topology of devices implementing the redundant transmission method, system, and device in a wireless network, or graphical output of the progress of any method or system considered herein.

[0125] It is understood that entities performing the steps shown herein, such as in Figures 7–9, may be logical entities. The steps may be stored in the memory of a device, server, or computer system, such as those shown in Figure 10F or Figure 10G, and executed on its processor. It is intended that steps may be skipped, steps may be combined, or steps may be added between the exemplary methods disclosed herein (e.g., Figures 7–9).

[0126] Table 1 or Table 2 contains 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 technology (New RAT), which is expected to include the provision of new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new non-backward compatible radio access in new spectrums below 6 GHz, and is expected to include different operating modes that can be multiplexed together on the same spectrum to address a wide range of 3GPP NR use cases with branching requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrums, providing opportunities for ultra-mobile broadband access for indoor applications and hotspots, for example. In particular, ultra-mobile broadband is expected to share a common design framework with flexible wireless access below 7GHz, utilizing centimeter-wave and millimeter-wave specific design optimizations.

[0130] 3GPP identifies a variety of use cases that NR is expected to support, resulting in diverse user experience requirements for data transfer speed, latency, and mobility. Common use cases include 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 saving), and enhanced vehicle-to-everything (eV2X) communications, which may include any of the following: vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle-to-everything communication with other entities. Specific services and applications in these categories include, to name a few, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first-person connectivity, automotive e-calls, disaster alerts, real-time gaming, multi-person video conferencing, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases are contemplated herein.

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

[0132] It will be understood that the concepts disclosed herein can be used with any number of WTRUs, base stations, networks, or network elements. Each of WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be any type of device or apparatus configured to operate or communicate in a wireless environment. Each WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g may be transmitted as a handheld wireless communication device as shown in Figures 10A, 10B, 10C, 10D, 10E, or 10F. However, in the diverse use cases envisioned for 5G wireless communication, each WTRU may be comprised of, or embodied in, any type of device or apparatus configured to receive or transmit wireless signals, including, but only as an example, user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, cars, buses, trucks, trains, or airplanes.

[0133] The communication system 100 may also include base stations 114a and 114b. In the example in Figure 10A, each base station 114a and 114b is illustrated as a single element. In practice, base stations 114a and 114b may include any number of interconnected base stations or network elements. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112. Similarly, base station 114b may be any type of device configured to interface via wired or wireless connection with at least one of the following: Remote Radio Head (RRH) 118a, 118b, Transmission and Reception Point (TRP) 119a, 119b, or Roadside Unit (RSU) 120a and 120b, in order to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, other networks 112, or network servers 113. RRH 118a, 118b may be any type of device configured to interface wirelessly with at least one of the following: WTRU 102, for example, WTRU 102c, in order to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112.

[0134] TRP119a, 119b may be any type of device configured to wirelessly interface with at least one of WTRU102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112. RSU120a, 120b may be any type of device configured to wirelessly interface with at least one of WTRU102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, or network services 113. For example, base stations 114a, 114b may be base transceiver stations (BTS), Node B, eNode B, home Node B, home eNode B, Next Generation Node-B (gNode B), satellites, site controllers, access points (AP), wireless routers, etc.

[0135] Base station 114a may be part of 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), and relay nodes. Similarly, base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations or network elements (not shown), such as a BSC, RNC, and relay nodes. Base station 114a may be configured to transmit or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, base station 114b may be configured to transmit or receive wired or wireless signals within a specific geographic area, which may be referred to as a cell (not shown) for redundant transmission methods, systems, and devices in a wireless network, as disclosed herein. Similarly, base station 114b may be configured to transmit or receive wired or wireless signals within a specific geographic 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 base station 114a may be divided into three sectors. Thus, in one example, base station 114a may include three transceivers, for example, one transceiver per sector of the cell. In one example, base station 114a may use multiple-input multiple output (MIMO) technology and thus utilize multiple transceivers for each sector of the cell.

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

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

[0138] RRH118a, 118b, TRP119a, 119b, or RSU120a, 120b may communicate with one or more WTRU102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0139] WTRU102a, 102b, 102c, 102d, 102e, or 102f may communicate with each other via air interface 115d / 116d / 117d (such as sidelink communication), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interface 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0140] The communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a of RAN 103 / 104 / 105, and WTRU 102a, 102b, 102c, or RRH 118a, 118b, TRP 119a, 119b, and RSU 120a, 120b of RAN 103b / 104b / 105b, as well as WTRU 102c, 102d, 102e, 102f, may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) and Terrestrial Radio Access (UTRA), which may use wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) or Advanced HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) or High-Speed ​​Uplink Packet Access (HSUPA).

[0141] In one embodiment, base stations 114a and WTRUs 102a, 102b, 102c, or RANs 103b / 104b / 105b, RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b, as well as WTRUs 102c, 102d, may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c, respectively, using Long Term Evolution (LTE) or LTE-Advanced (LTE-A). In the future, air interfaces 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 (such as sidelink communication). Similarly, 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communication).

[0142] Base stations 114a of RAN103 / 104 / 105 and WTRU102a, 102b, 102c, and 102g, or RRH118a, 118b, TRP119a, 119b, or RSU120a, 120b of RAN103b / 104b / 105b and WTRU102c, 102d, 102e, 102f are compliant with IEEE 802.16 (for example, Worldwide Interoperability for Microwave Access (WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Telephone). Wireless technologies such as GSM communications, Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN) can be implemented.

[0143] As disclosed herein, to implement methods, systems, and devices for redundant transmission in a wireless network, the base station 114c in Figure 10A may be, for example, a wireless router, home node B, home eNode B, or access point, and any suitable RAT may be used to facilitate wireless connectivity in local areas such as offices, homes, vehicles, trains, airborne, satellite, factories, and campuses. In embodiments, the base station 114c and WTRU 102, for example WTRU 102e, may establish a wireless local area network (WLAN) by performing radio technologies such as IEEE 802.11. Similarly, the base station 114c and WTRU 102d may establish a wireless personal area network (WPAN) by performing radio technologies such as IEEE 802.15. In yet another example, base stations 114c and WTRU 102, for example WTRU 102e, may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.). As shown in Figure 10A, base station 114c may have a direct connection to the internet 110. Therefore, base station 114c may not need to access the internet 110 via the core network 106 / 107 / 109.

[0144] RAN103 / 104 / 105 or RAN103b / 104b / 105b may communicate with core networks 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 WTRU102a, 102b, 102c, or 102d. For example, core networks 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 perform high-level security functions such as user authentication.

[0145] Although not shown in Figure 10A, it will be understood that 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 RAN 103 / 104 / 105 or RAN 103b / 104b / 105b, or with other RANs employing different RATs. For example, in addition to connecting to RAN 103 / 104 / 105 or RAN 103b / 104b / 105b, which may utilize E-UTRA radio technology, core network 106 / 107 / 109 may also communicate with other RANs (not shown) using GSM or NR radio technology.

[0146] Core networks 106 / 107 / 109 may also function as gateways for WTRUs 102a, 102b, 102c, 102d, and 102e to access PSTN 108, the Internet 110, or other networks 112. PSTN 108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as the transmission control protocol (TCP), the datagram protocol (UDP), and the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned or operated by other service providers. For example, 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 RAN 103 / 104 / 105 or RAN 103b / 104b / 105b, or a different RAT.

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

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

[0149] Figure 10B is a system diagram of an exemplary RAN103 and core network 106 that may implement redundant transmission methods, systems, and devices in a wireless network as disclosed herein. As described above, RAN103 may communicate with WTRU102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN103 may also communicate with core network 106. As shown in Figure 10B, RAN103 may include nodes B140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via air interface 115. Nodes B140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN103. RAN103 may also include RNC142a, 142b. It will be understood that RAN103 may contain any number of Node B and Wireless Network Controllers (RNCs).

[0150] As shown in Figure 10B, nodes B140a and B140b can communicate with RNC142a. Furthermore, node B140c can communicate with RNC142b. Nodes B140a, B140b, and B140c can communicate with their respective RNC142a and B142b via the Iub interface. RNC142a and B142b can communicate with each other via the Iur interface. Each of RNC142a and B142b may be configured to control their respective nodes B140a, B140b, and B140c to which it is connected. In addition, each of RNC142a and B142b may be configured to perform or support other functions such as external loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[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 aforementioned 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] RNC142a in RAN103 may be connected to MSC146 in core network 106 via IuCS interface. MSC146 may be connected to MGW144. MSC146 and MGW144 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices.

[0153] RNC142a within RAN103 may also be connected to SGSN148 in core network 106 via an IuPS interface. SGSN148 may be connected to GGSN150. SGSN148 and GGSN150 may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 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] Figure 10C is a system diagram of an exemplary RAN 104 and core network 107 that can implement redundant transmission methods, systems, and devices in a wireless network as disclosed herein. As described above, RAN 104 can communicate with WTRU 102a, 102b, and 102c via air interface 116 using E-UTRA wireless technology. RAN 104 can also communicate with core network 107.

[0156] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. For example, eNode-B160a, 160b, and 160c may perform MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit wireless signals to WTRU102a and receive wireless signals from WTRU102a.

[0157] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., in the uplink or downlink. As shown in Figure 10C, the eNode-B160a, 160b, and 160c may communicate with each other through the 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 aforementioned 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 MME162 can be connected to each of the eNode-B160a, 160b, and 160c within RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users for WTRU102a, 102b, and 102c, bearer activation / deactivation, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may also provide control plane functionality for exchanges between RAN104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

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

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

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

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

[0164] RAN105 may include gNode-B180a and 180b. It will be understood that RAN105 may include any number of gNode-B. Each of gNode-B180a and 180b may include one or more transceivers for communicating with WTRU 102a and 102b via air interface 117. When integrated access and backhaul connectivity is used, the same air interface may be used between the WTRU and the gNode-B, and this air interface may be a core network 109 via one or more gNBs. gNode-B180a and 180b may implement MIMO, MU-MIMO, or digital beamforming techniques. Thus, gNode-B180a may, for example, use multiple antennas to transmit wireless signals to and receive wireless signals from WTRU 102a. It should be understood that RAN105 may use other types of base stations, such as eNode-B. It should also be understood that RAN105 can employ two or more types of base stations. For example, RAN can use eNode-B and gNode-B.

[0165] N3IWF199 may include non-3GPP access points 180c. It will be understood that N3IWF199 may include any number of non-3GPP access points. Non-3GPP access points 180c may include one or more transceivers for communicating with WTRU102c via air interface 198. Non-3GPP access points 180c may communicate with WTRU102c via air interface 198 using the 802.11 protocol.

[0166] Each of the gNode-B180a and 180b may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., on the uplink or downlink. As shown in Figure 10D, the gNode-B180a and 180b may communicate with each other, for example, through the Xn interface.

[0167] The core network 109 shown in Figure 10D may be a 5G core network (5GC). The core network 109 may provide numerous communication services to customers interconnected by wireless access networks. The core network 109 includes several entities that perform the functionality of the core network. As used herein, the terms “core network entity” or “network function” refer to any entity that performs one or more functions of the core network. Such core network entities may be devices configured for wireless or network communications, or logical entities implemented in the form of computer executable instructions (software) stored in the memory of a computer system such as system 90 shown in Figure 10G and executed on its processors.

[0168] In the example in Figure 10D, the 5G core network 109 may include an access and mobility management function (AMF) 172, a session management function (SMF) 174, user plane functions (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 aforementioned elements is illustrated as part of the 5G core network 109, it should be understood that any of these elements may be owned or operated by entities other than the core network operator. Furthermore, it should be understood that a 5G core network may not necessarily include all of these elements, and may include additional elements, and may include multiple instances of each of these elements. Figure 10D shows network functions directly connected to each other, but it should be understood that they can communicate via routing agents such as a diameter routing agent or a message bus.

[0169] In the example in Figure 10D, connectivity between network functions is achieved through a set of interfaces or reference points. It will be understood 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, or invocation of software functions.

[0170] AMF172 can be connected to RAN105 via the N2 interface and can function as a control node. For example, AMF172 can perform registration management, connection management, reachability management, access authentication, and access authorization roles. AMF can forward user plane tunnel configuration information to RAN105 via the N2 interface. AMF172 can receive user plane tunnel configuration information from SMF via the N11 interface. Generally, AMF172 can route and forward NAS packets to and from WTRU 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in Figure 10D.

[0171] SMF174 can be connected to AMF172 via the N11 interface. Similarly, SMF can be connected to PCF184 via the N7 interface and to UPF176a and 176b via the N4 interface. SMF174 can function as a control node. For example, SMF174 may be responsible for session management, IP address assignment for WTRU102a, 102b, and 102c, management and configuration of traffic steering rules in UPF176a and UPF176b, and generation of downlink data notifications to AMF172.

[0172] UPF176a and UPF176b may provide WTRU102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communication between WTRU102a, 102b, and 102c and other devices. UPF176a and UPF176b may also provide WTRU102a, 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 data packets. UPF176a and UPF176b may receive traffic steering rules from SMF174 via the N4 interface. UPF176a and UPF176b may provide access to a packet data network by connecting it to the N6 interface or by connecting it to each other or to other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF176 can play a role in packet routing and forwarding, enforcement of policy rules, quality of service for user plane traffic, and downlink packet buffering.

[0173] AMF172 can also be connected to N3IWF199, for example, via the N2 interface. N3IWF facilitates connectivity between WTRU102c and the 5G core network 170, for example, via radio interface technology not defined by 3GPP. AMF can interact with N3IWF199 in the same or similar manner as it interacts with RAN105.

[0174] PCF184 may be connected to SMF174 via the N7 interface, to AMF172 via the N15 interface, and to Application Function (AF) 188 via the N5 interface. The N15 and N5 interfaces are not shown in Figure 10D. PCF184 may also provide policy rules to control plane nodes such as AMF172 and SMF174, enabling the control plane nodes to enforce these rules. PCF184 can send policies to AMF172 for WTRU102a, 102b, and 102c, and AMF can deliver the policies to WTRU102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied in WTRU102a, 102b, and 102c.

[0175] UDR178 can function as a repository for authentication certificates and membership information. UDR may connect to network functions, which can append to, read, and modify data in the repository. For example, UDR178 may connect to PCF184 via the N36 interface. Similarly, UDR178 may connect to NEF196 via the N37 interface, and UDR178 may connect to UDM197 via the N35 interface.

[0176] The UDM197 can function as an interface between the UDR178 and other network functions. The UDM197 can authorize network functions for access to the UDR178. For example, the UDM197 can connect to the AMF172 via the N8 interface, and to the SMF174 via the N10 interface. Similarly, the UDM197 can connect to the AUSF190 via the N13 interface. The UDR178 and UDM197 can be tightly integrated.

[0177] The AUSF190 performs authentication-related operations and connects to the UDM178 via the N13 interface and to the AMF172 via the N12 interface.

[0178] NEF196 exposes the capabilities and services of the 5G core network 109 to the application function (AF) 188. Exposure may occur via the N33 API interface. The NEF may connect to AF188 via the N33 interface, or it may connect to other network functions to expose the capabilities and services of the 5G core network 109.

[0179] The application function 188 may interact with network functions within the 5G core network 109. The interaction between the application function 188 and the network functions may occur via a direct interface or via the NEF 196. The application function 188 may be considered part of the 5G core network 109, or it may be outside the 5G core network 109 and deployed by a company that has a business relationship with a mobile network operator.

[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 that provide optimized solutions for different market scenarios requiring 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., large-scale IoT, critical communications, V2X, and enhanced mobile broadband) that require highly varied and sometimes extreme requirements. Without using network slicing technology, the network architecture is likely to lack sufficient flexibility and scalability to efficiently support a wider range of use cases, as each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, it should make the deployment of new network services more efficient.

[0182] Referring again to Figure 10D, in the network slicing scenario, WTRU102a, 102b, or 102c may be connected to AMF172 via the N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of WTRU102a, 102b, or 102c to one or more UPF176a and 176b, SMF174, and other network functions. Each of the UPF176a and 176b, SMF174, 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 have different computing resources, security certificates, 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 functions 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 the Short Message Service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and the server or application function 188. In addition, the core network 170 may provide WTRUs 102a, 102b, and 102c with access to 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, but future entities and functions may be identified by other names, and it is understood that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Accordingly, the specific network entities and functions described and shown in Figures 10A, 10B, 10C, 10D, or 10E are provided as examples only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or hereafter defined.

[0185] Figure 10E shows an exemplary communication system 111 in which systems, methods, and apparatus for implementing redundant transmission in a wireless network, as described herein, may be used. The communication system 111 may include wireless transmission / receiving 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 station gNBs, V2X networks, or other network elements. One or more, or all, WTRUs A, B, C, D, E, and F may be outside the coverage 131 of the 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 can communicate with each other via the Uu interface 129 through the gNB 121 if they are within access network coverage 131. In the example in Figure 10E, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may also communicate directly with each other via sidelink interfaces such as interfaces 125a, 125b, or 128 (e.g., PC5 or NR PC5), regardless of whether they are under or outside access network coverage 131. For example, in the example in Figure 10E, WTRU D, which is outside access network coverage 131, communicates with WTRU F, which is within coverage 131.

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

[0188] Figure 10F is a block diagram of an exemplary apparatus or device WTRU102 that may be configured for wireless communication and operation by a system, method, and apparatus for implementing redundant transmission in a wireless network, as described herein, such as WTRU102 (e.g., UE) in Figures 1-9, as shown herein. As shown in Figure 10F, the exemplary WTRU102 may include a processor 118, a transceiver 120, a transmission / reception element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that WTRU102 may include any partial combination of the aforementioned elements. Furthermore, base stations 114a and 114b, or base stations 114a and 114b, may represent, but are not limited to, a number of transceiver stations (BTS), nodes B, site controllers, access points (APs), home nodes B, evolved home nodes B (eNodeB), home evolved nodes B (HeNB), home evolved node B gateways, next-generation nodes B (gNode-B), and proxy nodes, and may include some or all of the elements illustrated in Figure 10F, and may be exemplary implementations of the disclosed systems and methods for redundant transmission in a wireless network (e.g., 5G) as described herein.

[0189] The processor 118 may be a general-purpose processor, a dedicated 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 a transceiver 120 which can be coupled to a transmission / reception element 122. Figure 10F shows the processor 118 and the transceiver 120 as separate components, but it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0191] In addition, although the transmission / receiving element 122 is illustrated as a single element in Figure 10F, the WTRU 102 may include any number of transmission / receiving elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Therefore, the WTRU 102 may include two or more transmission / receiving elements 122 (e.g., multiplex antennas) for transmitting and receiving wireless signals via the air interfaces 115 / 116 / 117.

[0192] The transceiver 120 may be configured to modulate the signal transmitted by the transmission / receiving element 122 and demodulate the signal received by the transmission / receiving element 122. As described above, the WTRU 102 may have multimode capability. Therefore, 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 WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, or a display / touchpad / indicator 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from them. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, or the display / touchpad / indicator 128. Furthermore, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 or removable memory 132, and store data in that memory. 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. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, or a secure digital This may include digital (SD) memory cards, etc. The processor 118 may access information from memory not physically located on the WTRU 102, such as on a server hosted on a cloud or edge computing platform or a home computer (not shown), and store data in that memory. The processor 118 may be configured to control a lighting pattern, image, or color on the display or indicator 128, or to otherwise indicate the status of redundant transmission and associated components in a wireless network, depending on whether the setting of redundant messages was successful or unsuccessful for some of the embodiments described herein. The controlled lighting pattern, image, or color on the display or indicator 128 may reflect the status of any of the method flows or components in the figures shown or considered herein (e.g., Figures 6-7, etc.).This specification discloses messages and procedures for redundant transmission in a wireless network. The messages and procedures may be extended to provide an interface / API for a user to request, configure, or query redundant transmission in wireless network-related information, among other things that may be displayed on the display 128, and to request resources via an input source (e.g., speaker / microphone 124, keypad 126, or display / touchpad / indicator 128).

[0194] The processor 118 may receive power from the power supply 134 and may be configured to distribute or control power to other components within the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 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) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117, or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by any preferred location determination method.

[0196] The processor 118 may be further coupled to other peripherals 138 and may include one or more software or hardware modules that provide additional features, functions, 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 photography or video), 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, or a video game player module.

[0197] WTRU102 may be included in sensors, household electrical appliances, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, automobiles, trucks, trains or other vehicles, or other devices such as airplanes. WTRU102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface which may include one of the peripheral devices 138.

[0198] Figure 10G is a block diagram of an exemplary computing system 90 in which redundant transmission in a wireless network can be embodied, including one or more devices of the communication network shown in Figures 10A, 10C, 10D, and 10E, such as RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, other networks 112, or specific nodes or functional entities in network services 113, as described and claimed herein, as well as the systems and methods shown in Figures 1 to 9. 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 by any means through 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 tasks. The processor 91 may be a general-purpose processor, a dedicated 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 on a communication network. The coprocessor 81 is an optional processor distinct from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 or 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] During operation, the processor 91 fetches, decodes, and executes instructions, and transmits information to other resources via the main data transfer path of the computing system, the system bus 80. Such a system bus connects the components within the computing system 90 and defines the 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 the PCI (Peripheral Component Interconnect) bus.

[0200] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that enables information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. Data stored in RAM 82 can be read or modified by the processor 91 or other hardware devices. Access to RAM 82 or ROM 93 can be controlled by the memory controller 92. When an instruction is executed, the memory controller 92 can provide address translation functionality that translates virtual addresses to physical addresses. The memory controller 92 can also provide memory protection functionality that isolates processes within 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's virtual address space unless inter-process memory sharing is configured.

[0201] In addition, the computing system 90 may include a peripheral device controller 83 that plays a role in communicating commands from the 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 as 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 includes the electronic components necessary to generate the video signal transmitted to the display 86.

[0203] Furthermore, the computing system 90 may include communication circuits, such as a wireless or wired network adapter 97, which can be used to connect the computing system 90 to external communication networks or devices such as RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, WTRU 102, or other networks 112 in Figures 10A, 10B, 10C, 10D, or 10E, enabling the computing system 90 to communicate with other nodes or functional entities in those networks. The communication circuits may be used alone or in combination with the processor 91 to perform the transmission and reception steps of the specific devices, nodes, or functional entities described herein.

[0204] Any or all of the apparatus, 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, and it is understood that when such instructions are executed by a processor, such as processor 118 or 91, the processor will carry out or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions that are executed on a processor of an apparatus or computing system configured for wireless or wired network communication. Computer-readable storage mediums include volatile and non-volatile, removable and non-removable media for storing information, which are implemented by any non-temporary (e.g., tangible or physical) method or technique, but such computer-readable storage mediums do not contain signals. Computer-readable storage media include RAM, ROM, EEPROM, flash memory, or other memory technologies; CD-ROM, digital versatile disks (DVDs), or other optical disk storage; magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices; or any other tangible or physical media that can be used to store desired information and can be accessed by a computing system.

[0205] In describing preferred methods, systems, or apparatus of the subject matter of this disclosure (redundant transmission in wireless networks), certain terms are used for clarity, as shown in the figures. However, the claimed subject matter is not intended to be limited to the specific terms thus selected.

[0206] The various technologies described herein may be implemented in relation to hardware, firmware software, or, as appropriate, a combination thereof. Such hardware, firmware, and software may reside in devices located at various nodes of a communication network. The devices may operate individually or in combination with each other to implement the methods described herein. As used herein, terms such as “device,” “network device,” “node,” “device,” and “network node” may be used interchangeably. In addition, the use of the word “or” is generally used comprehensively unless otherwise specified herein.

[0207] This specification provides examples for the disclosed subject matter, including the best form, and enables a person skilled in the art to practice the disclosed subject matter, including making and using any device or system, and performing any incorporated method. The disclosed subject matter may include other examples conceivable by a person skilled in the art, such as skipping steps, combining steps, or adding steps between the exemplary methods disclosed herein.

[0208] In particular, the methods, systems, and apparatus described herein may provide redundant transmission in a 5G network. The methods, systems, computer-readable storage media, or apparatus provide triggering a PDU session change process to trigger a redundant transmission stop, sending an N2 SM message to an SMF1 to request a change in PDU session 1, and forwarding the PDU session change message to an SMF1. These steps may be performed by a user equipment (UE) or a radio access network (RAN) node. A method, system, computer-readable storage medium, or apparatus provides for 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 and second PDU sessions based on the configuration; transmitting the PSPI to the 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 and second PDU sessions are associated with a data network name (DNN) or a single network Different combinations of Network Slice Selection Support Information (S-NSSAI) may be associated. A method, system, computer-readable storage medium, or apparatus provides receiving 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, and that notifying the RAN node that the first PDU session is associated with a second PDU session is done by sending the PSPI to the AMF, which then forwards the PSPI to the RAN node in an N2 message. All combinations in this paragraph (including the removal or addition of steps) are intended to be consistent with other parts of the detailed description.

Claims

1. A method performed by a user device, A user equipment route selection policy (URSP) rule for associating application traffic with a packet data unit (PDU) session and detecting that application traffic is associated with redundant transmission, the URSP rule includes at least two route selection descriptors (RSDs), and the system receives the URSP rule. Using the first URSP rule, determine that the first application traffic for the first PDU session is associated with the first RSD and redundant transmission, Using a second URSP rule, determine that the second application traffic for the second PDU session is associated with the second RSD and the redundant transmission, Determining PDU session pair information (PSPI) to associate with a first message associated with the first PDU session and with a second message associated with the second PDU session, Sending the PSPI in the first message associated with the first PDU session, A method comprising sending the PSPI in the second message associated with the second PDU session.

2. The method according to claim 1, wherein the application traffic is identified by a data network name or an IP address.

3. The first message includes a first PDU session establishment message, The method according to claim 1, wherein the second message includes a second PDU session establishment message.

4. The first message is for establishing the first PDU session, The method according to claim 1, wherein the second message is for establishing the second PDU session.

5. The method according to claim 1, wherein the PSPI is obtained via an AT command.

6. The method according to claim 1, wherein the first PDU session and the second PDU session are associated with different combinations of data network names (DNNs) or single network slice selection support information (S-NSSAI).

7. The method according to claim 1, wherein the PSPI is transmitted to the network management function.

8. The method according to claim 1, wherein the PSPI includes an identifier.

9. User equipment, Processor and The processor comprises a memory coupled to the processor, wherein the memory includes executable instructions stored in the memory, and when an instruction is executed by the processor, the processor: A user equipment route selection policy (URSP) rule for associating application traffic with a packet data unit (PDU) session and detecting that application traffic is associated with redundant transmission, the URSP rule includes at least two route selection descriptors (RSDs), and the system receives the URSP rule. Using the first URSP rule, determine that the first application traffic for the first PDU session is associated with the first RSD and redundant transmission, Using a second URSP rule, determine that the second application traffic for the second PDU session is associated with the second RSD and the redundant transmission, Determining PDU session pair information (PSPI) to associate with a first message associated with the first PDU session and with a second message associated with the second PDU session, Sending the PSPI in the first message associated with the first PDU session, A user device that causes the second message associated with the second PDU session to transmit the PSPI.

10. The user device according to claim 9, wherein the application traffic is identified by a data network name or an IP address.

11. The first message includes a first PDU session establishment message, The user device according to claim 9, wherein the second message includes a second PDU session establishment message.

12. The first message is for establishing the first PDU session, The user device according to claim 9, wherein the second message is for establishing the second PDU session.

13. The user device according to claim 9, wherein the PSPI is obtained via an AT command.

14. The user device according to claim 9, wherein the first PDU session and the second PDU session are associated with different combinations of data network names (DNNs) or single network slice selection support information (S-NSSAI).

15. The user device according to claim 9, wherein the PSPI is transmitted to the network management function.

16. The user device according to claim 9, wherein the PSPI includes an identifier.

Images