[go: up one dir, main page]

WO2019158219A1 - Ran device and core network device for network slicing - Google Patents

Ran device and core network device for network slicing Download PDF

Info

Publication number
WO2019158219A1
WO2019158219A1 PCT/EP2018/054037 EP2018054037W WO2019158219A1 WO 2019158219 A1 WO2019158219 A1 WO 2019158219A1 EP 2018054037 W EP2018054037 W EP 2018054037W WO 2019158219 A1 WO2019158219 A1 WO 2019158219A1
Authority
WO
WIPO (PCT)
Prior art keywords
qos
correlation information
sessions
network
joint
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2018/054037
Other languages
French (fr)
Inventor
Ömer BULAKCI
Qing Wei
Karthikeyan Ganesan
Ali Ramadan ALI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Duesseldorf GmbH
Original Assignee
Huawei Technologies Duesseldorf GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Duesseldorf GmbH filed Critical Huawei Technologies Duesseldorf GmbH
Priority to PCT/EP2018/054037 priority Critical patent/WO2019158219A1/en
Publication of WO2019158219A1 publication Critical patent/WO2019158219A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0247—Traffic management, e.g. flow control or congestion control based on conditions of the access network or the infrastructure network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS

Definitions

  • the present invention relates to the field of network slicing, as e.g. implemented in fifth generation (5G) mobile and wireless communications system.
  • the present invention provides a Radio Access Network (RAN) device for providing/supporting multiple network slices and/or sessions for a service or application.
  • the present invention also provides a Core Network (CN) device for providing/supporting multiple network slices and/or sessions for an application or service.
  • the RAN and CN devices are able to perform a joint Quality of Service (QoS) treatment on the multiple slices and/or sessions, in order to improve the support for multi-slice services or applications.
  • QoS Quality of Service
  • the network slicing concept is introduced in 5G to address the various requirements, particularly from multiple vertical industries assuming a shared network infrastructure.
  • Network services can be customized based on the requirements of different use cases, and thus can increase the network operation efficiency.
  • the 5G network will provide various types of network services over the shared infrastructure by means of the network slicing concept, wherein:
  • the network management system is responsible for the instantiation and management of the network slice(s) over the shared infrastructure (resources, devices, physical links, etc.).
  • Each network slice may be supported by tailored Network Functions (NFs), such as a User Plane Function (UPF), Session Management Function (SMF), or Access and Mobility management Function (AMF).
  • NFs Network Functions
  • UPF User Plane Function
  • SMF Session Management Function
  • AMF Access and Mobility management Function
  • Network slices can be assigned to dedicated sources, e.g. a spectrum or a given spectrum band can be shared by different network slices considering Service Level Agreements (SLAs) of the network slices.
  • SLAs Service Level Agreements
  • Network slices can be identified by slice IDs, e.g., Single Network Slice Selection Assistance Information (S-NSSAI) which comprises Slice/Service type (SST) and optionally a Slice Differentiator (SD).
  • S-NSSAI Single Network Slice Selection Assistance Information
  • SST Slice/Service type
  • SD Slice Differentiator
  • a slice ID can be extended or modified to identify a RAN part of a network slice and a CN part of a network slice.
  • UEs User Equipments
  • AMF Access Management Function
  • the SMF can establish/modify/teardown a session (e.g. Protocol Data Unit (PDU) session) and correspondent User Plane per slice.
  • a session e.g. Protocol Data Unit (PDU) session
  • PDU Protocol Data Unit
  • Basic network slice types are defined in 3GPP and defined as per an SST. Slice types are, for example, enhanced Mobile Broadband (eMBB), massive Machine-Type Communication (mMTC), and Ultra Reliable Low Latency Communications (URLLC). Each network SST is designed for a group of services sharing similar service requirements.
  • eMBB enhanced Mobile Broadband
  • mMTC massive Machine-Type Communication
  • URLLC Ultra Reliable Low Latency Communications
  • FIG. 12 shows an example scenario, in which a 5G car is associated with two network slices (i.e. the car may be referred to as a multi-slice UE), namely, URLLC and eMBB slices.
  • a part of the 5G core NFs are shown, wherein the AMF is shared by the two network slices, and wherein the SMF and UPF are tailored for the network slices.
  • the Data Networks (DNs) can be the same.
  • the 5G car is connected to a RAN device, e.g. a Base Station (BS), here named as gNB (next generation Node B).
  • BS Base Station
  • gNB next generation Node B
  • applications/services can use multiple network slices.
  • FIG. 13 illustrates an example use case, in particular the use case of remote driving, where similar data flows can also exist in case of tele-presence remote diagnosis.
  • this use case :
  • HD video transmission requires high throughput on the uplink (UL), which is supported by the eMBB slice.
  • the remote operator may require synchronized haptic feedback along with the HD video.
  • AR Augmented Reality
  • VR Virtual Reality
  • haptic feedback and video control on the Uplink (UL) - supported by the URLLC slice - and segmented video data on the Downlink (DL) - supported by the eMBB slice - can be required.
  • a PDU session belongs to one and only one specific network slice instance per Public Land Mobile Network (PLMN). Different network slice instances do not share a PDU session (see e.g. 3GPP TS 23.501).
  • PLMN Public Land Mobile Network
  • the Next Generation (NG)-RAN maps packets belonging to different PDU sessions to different Data Radio Bearers (DRBs).
  • DRBs Data Radio Bearers
  • the NG-RAN establishes at least one default DRB for each PDU session indicated by the 5G Core Network (5GC) upon PDU session establishment (see e.g. RAN2 TS 38.300).
  • 5GC 5G Core Network
  • FIG. 14 An example multi-slice UE support considering the current implementation of network slicing is illustrated in FIG. 14.
  • an independent QoS flow treatment is applied. This QoS flow treatment, however, is suboptimal for many use cases, and the application requirements may thus not be fulfilled.
  • the present invention aims to improve the current implementation for network slicing.
  • the present invention has the objective to provide improved multi-slice service or application support.
  • the present invention has the goal that the service or application requirements are fulfilled also in cases where an application or service is associated with multiple network slices.
  • One intention is to enable a dependent (i.e. a joint) QoS treatment of different network slices for the same application or service.
  • the present invention aims also for utilizing an identified correlation between different network slices.
  • Various aspects provided herein can be applied to the case when a service or application is supported by at least two sessions or data flows within a network slice.
  • the current implementations do not support any efficient cross slice optimization/ inter-slice coordination.
  • the present invention proposes a correlated QoS treatment considering that correlation(s) exists between service requirements of different network slices for the same application or service.
  • the performance of one network slice affects the required key performance indicator (KPI) of another correlated network slice.
  • KPI key performance indicator
  • AR/VR e.g. long latency of video control (direction of view).
  • inter-dependency between network slices can be reflected by translating the individual KPI requirement of each network slice into one or more joint KPIs e.g. by analyzing the service request from each network slice.
  • Such joint KPIs can be shared to the next generation - RAN (NG-RAN) from the 5G core (5GC) and/or 5G management system, e.g. by the Network Slice Management Function (NSMF) and the Network Slice Subnet Management Function (NSSMF).
  • NG-RAN next generation - RAN
  • the NSMF may split end-to-end (e2e) KPIs into the KPI quota in different domains (e.g. CN, RAN, and transport network-TN) and can send it to the NSSMF or inform the NSSMF of the KPI correlation between associated (correlated) network slices.
  • the domain specific cross-slice management and orchestration in the NSSMF can perform inter-slice optimization within its domain (e.g. as self-organizing network- SON procedure).
  • a first aspect of the present invention provides a RAN, device for providing at least one terminal device with at least two network slices and/or at least two sessions of a network slice for an application or service, the RAN device being configured to obtain correlation information between the at least two network slices and/or at least two sessions of a network slice, and perform a joint Quality of Service, QoS, treatment for the at least two network slices and/or the at least two sessions based on the correlation information.
  • QoS Quality of Service
  • the RAN may thus be configured with the at least two network slices and/or sessions.
  • a correlation information can include one or more identifiers, in particular for one or more slices, for one or more sessions, and/or for one or more data flows.
  • the RAN device is configured to perform the joint QoS treatment by adjusting at least one QoS parameter for each of the at least two network slices and/or sessions based on the correlation information.
  • the correlation information is between a first session of a first network slice and a second session of the first network slice and/or a second network slice
  • the RAN device is configured to adjust at least one QoS parameter of each QoS flow belonging to the first session and each QoS flow belonging to the second session, respectively, based on the correlation information.
  • the correlation information is obtained on a session level, and the joint QoS treatment is performed accordingly on sessions.
  • the correlation information is between a first QoS flow belonging to a session of a first network slice and a second QoS flow belonging to a session of the first network slice and/or a second network slice
  • the RAN device is configured to adjust at least one QoS parameter of the first QoS flow and the second QoS flow, respectively, based on the correlation information.
  • the correlation information is obtained on a QoS flow level, and the joint QoS treatment is performed accordingly on QoS flows. This can provide a finer granularity than joint QoS treatment on sessions.
  • the correlation information is between a first packet sequence of a QoS flow belonging to a session of a first network slice and a second packet sequence of a QoS flow belonging to a session of the first network slice and/or a second network slice
  • the RAN device is configured to adjust at least one QoS parameter of the first packet sequence and the second packet sequence, respectively, based on the correlation information.
  • a packet sequence can be at least one packet.
  • the correlation information is obtained on a packet sequence level, and the joint QoS treatment is performed accordingly on packet sequences of QoS flows. This provides an even finer granularity than joint QoS treatment on QoS flows.
  • the joint QoS treatment includes at least one of: joint allocating and/or scheduling of radio resources; adapting a joint Key Performance Indicator, KPI; considering a joint Automatic Retention Policy, ARP; joint Radio Resource Management, RRM; selecting a joint packet delay budget; modifying QoS profiles and QoS rules of the correlated QoS flows; QoS flow synchronization of the correlated QoS flows; QoS flow prioritization for correlated QoS flows; logical channel prioritization and medium access control (MAC) reconfiguration; radio bearer modification.
  • the joint QoS treatment may also include joint admission control.
  • logical channel prioritization in RAN can take care of joint delay budget, e.g., packet delay budget (PDB), joint numerology configuration as part of logical channel restrictions and radio bearer configuration for joint QoS treatment.
  • PDB packet delay budget
  • joint numerology configuration as part of logical channel restrictions
  • radio bearer configuration for joint QoS treatment.
  • the joint QoS treatment includes prioritizing correlated QoS flows or correlated packet sequences of QoS flows over non- correlated QoS flows or packet sequences of QoS flows, respectively, based on the correlation information.
  • the RAN device is configured to receive the correlation information from a Core Network, CN, device, and/or provide the correlation information to the terminal device.
  • the transmission of the correlation information to the terminal device can be performed via non-access stratum (NAS) procedures, e.g., via Nl interface.
  • NAS non-access stratum
  • a second aspect of the present invention provides a CN device for providing a terminal device with at least two network slices and/or at least two sessions of a network slice for an application or service, the CN device being configured to determine correlation information between the at least two network slices and/or sessions, and provide the correlation information to a RAN device.
  • the RAN device may, for instance, be the RAN device of the first aspect.
  • the CN device can include 5G core network functions, such as AMF, SMF and UPF.
  • AMF Access Management Function
  • SMF Session Management Function
  • UPF User Plane Function
  • the RAN device may perform the joint QoS treatment based on the correlation information as described above.
  • the CN device is configured to determine the correlation information between sessions of the at least two network slices.
  • the CN device may determine the correlation information between a first session of a first network slice and a second session of the first network slice and/or a second network slice.
  • the correlation information is determined on a session level.
  • the CN device is configured to determine the correlation information between QoS flows belonging to sessions of the at least two network slices.
  • the CN device may determine the correlation information between a first QoS flow belonging to a session of a first network slice and a second QoS flow belonging to a session of the first network slice and/or a second network slice.
  • the correlation information is obtained on a QoS flow level. This provides a finer granularity than the determination on the session level.
  • the CN device is configured to determine the correlation information between packet sequences of QoS flows belonging to sessions of the at least two network slices.
  • the CN device may determine the correlation information between a first packet sequence of a QoS flow belonging to a session of a first network slice and a second packet sequence of a QoS flow belonging to a session of the first network slice and/or a second network slice.
  • a packet sequence may be at least one packet.
  • the correlation information is obtained on a packet level. This provides an even finer granularity than the determination on the QoS flow level.
  • the correlation information comprises at least one of: a correlation between service requirements of the at least two network slices and/or sessions for the service or application; a correlation between performances of the at least two network slices and/or sessions for the service or application; a shared latency budget between the at least two network slices and/or sessions for the service or application.
  • the service requirements of different network slices for the same application or service can be better fulfilled. Further, the performance can be improved. Further, the performance can be also a predicted or estimated performance.
  • the CN device is configured to receive a request for joint QoS treatment from the terminal device, and determine the correlation information based on the received request.
  • the joint QoS treatment is triggered by the user.
  • the information provided in the request by user can be used to determine correlation information by the CN device. Such information may be provided by an application of the user and/or as part of NAS service request from the user.
  • the request for joint QoS treatment can include a request for specific QoS handling, e.g., a correlation indication for selected service data flow(s) (SDFs), and Packet Filters describing the SDF(s).
  • SDFs selected service data flow(s)
  • Packet Filters describing the SDF(s).
  • Such correlation indication can be used by the CN device to bind the applicable SDF(s) on QoS Flows.
  • the CN device is configured to perform a joint QoS treatment for the at least two network slices and/or sessions based on the correlation information.
  • QoS parameters like QoS profiles and QoS Rules can be modified by the CN device to abide by the joint requirements.
  • QoS parameters like QoS profiles and QoS Rules can be modified by the CN device to abide by the joint requirements.
  • the support for multi-slice services or applications is further improved.
  • a third aspect of the present invention provides a terminal device for using at least two network slices and/or at least two sessions of a network slice for an application or service, the terminal device being configured to obtain or determine correlation information between the at least two network slices and/or sessions, and transmit the correlation information to a RAN or a CN-device; and/or perform a joint QoS treatment for the at least two network slices and/or sessions based on the correlation information.
  • the terminal device supports multi-slice services or applications in an improved manner. In particular, it can support the optimization of the throughput, and network efficiency, and the meeting of the service or application requirements.
  • the terminal device is configured to receive further correlation information from a RAN or a CN device; and perform a joint QoS treatment for the at least two network slices and/or sessions based on the further correlation information.
  • a fourth aspect of the present invention provides a method for providing at least two network slices and/or at least two sessions of a network slice for an application or service, the method comprising obtaining or determining correlation information between the at least two network slices and/or at least two sessions of a network slice, and performing a joint Quality of Service, QoS, treatment for the at least two network slices and/or the at least two sessions based on the correlation information.
  • QoS Quality of Service
  • the method comprises performing the joint QoS treatment by adjusting at least one QoS parameter for each of the at least two network slices and/or sessions based on the correlation information.
  • the correlation information is between a first session of a first network slice and a second session of the first network slice and/or a second network slice, and the method comprises adjusting at least one QoS parameter of each QoS flow belonging to the first session and each QoS flow belonging to the second session, respectively, based on the correlation information.
  • the correlation information is between a first QoS flow belonging to a session of a first network slice and a second QoS flow belonging to a session of the first network slice and/or a second network slice, and the method comprises adjusting at least one QoS parameter of the first QoS flow and the second QoS flow, respectively, based on the correlation information.
  • the correlation information is between a first packet sequence of a QoS flow belonging to a session of a first network slice and a second packet sequence of a QoS flow belonging to a session of the first network slice and/or a second network slice
  • the method comprises adjusting at least one QoS parameter of the first packet sequence and the second packet sequence, respectively, based on the correlation information.
  • the joint QoS treatment includes at least one of: joint allocating and/or scheduling of radio resources; adapting a joint Key Performance Indicator, KPI; considering a joint Automatic Retention Policy, ARP; joint Radio Resource Management, RRM; selecting a joint packet delay budget; modifying QoS profiles and QoS rules of the correlated QoS flows; QoS flow synchronization of the correlated QoS flows; QoS flow prioritization for correlated QoS flows; logical channel prioritization and MAC reconfiguration; radio bearer modification.
  • the joint QoS treatment includes prioritizing correlated QoS flows or correlated packet sequences of QoS flows over non- correlated QoS flows or packet sequences of QoS flows, respectively, based on the correlation information.
  • the method comprises receiving the correlation information from a CN device, and/or providing the correlation information to the terminal device.
  • the method of the fourth aspect and its implementation forms achieve the same advantages and effects as described above for the previous aspects and implementation forms, particularly of the RAN device of the first aspect. It has to be noted that the joint QoS treatment can be performed on different granularities, e.g., between QoS flow and packet sequence.
  • FIG. 1 shows a RAN device according to an embodiment of the present invention.
  • FIG. 2 shows a CN device according to an embodiment of the present invention.
  • FIG. 3 shows a terminal device according to an embodiment of the present invention.
  • FIG. 4 shows a method for correlated QoS treatment according to an embodiment of the present invention.
  • FIG. 5 shows an example of a correlated QoS treatment considering a PDU session- level correlation by a RAN or CN device according to an embodiment of the present invention.
  • FIG. 6 shows an example of correlated QoS treatment considering QoS flow-level correlation by a RAN or CN device according to an embodiment of the present invention.
  • FIG. 7 shows an example of correlated QoS treatment considering a Packet
  • FIG. 8 shows an example of dynamic QoS adjustment by a CN device according to an embodiment of the present invention.
  • FIG. 9 shows an example of a NG-RAN execution for a correlated QoS treatment by a RAN device according to an embodiment of the present invention.
  • FIG. 10 shows an example of scheduling for a correlated QoS treatment on UL.
  • FIG. 11 shows an example of scheduling for correlated QoS treatment on UL
  • FIG. 12 shows an exemplary illustration of a multi-slice terminal device (UE).
  • UE multi-slice terminal device
  • FIG. 13 shows an example of a use case for remote driving.
  • FIG. 14 shows an example of conventional multi-slice UE support with different
  • FIG. 1 shows a RAN device 100 according to an embodiment of the present invention.
  • the RAN device 100 is configured to provide at least one terminal device 101 with at least two network slices 102 and/or at least two sessions 105 of a network slice 102 for an application or service.
  • the directions of the arrows do not imply a limitation to a data flow direction, i.e., data flows can be on the downlink and/or uplink.
  • the RAN device 100 is configured to obtain correlation information 103 between the at least two network slices 102 and/or at least two sessions 105 of a network slice 102. Then, the RAN device 100 is configured to perform a joint QoS treatment 104 for the at least two network slices 102 and/or the at least two sessions 105 based on the correlation information 103. Due to the joint QoS treatment, the service or application using the at least two network slices 102 or sessions 105 can be better supported. In particular, all service or application requirements for the different slices 102 or sessions 105 can be met.
  • FIG. 2 shows a CN device 200 according to an embodiment of the present invention.
  • the CN device 200 is configured to provide a terminal device 101 with at least two network slices 102 and/or at least two sessions 105 of a network slice (not explicitly shown) for an application or service.
  • the directions of the arrows do not imply a limitation to a data flow direction.
  • the CN device 200 is configured to determine correlation information 103 between the at least two network slices 102 and/or sessions, and to provide the determined correlation information 103 to a RAN device.
  • the RAN device may be the RAN device 100 shown in FIG. 1.
  • the RAN device 100 is enabled to perform the joint QoS treatment 104 for the at least two network slices 102 and/or sessions 105.
  • the CN device 200 supports the service or application using the different network slices 102 and/or sessions 105.
  • FIG. 3 shows a terminal device 300 according to an embodiment of the present invention.
  • the terminal device 300 is configured to use at least two network slices 102 and/or at least two sessions 105 (not explicitly shown) of a network slice 102 for an application or service.
  • the terminal device 300 may be the terminal device 101 shown in FIG. 1 and FIG. 2, respectively. Again, the directions of the arrows do not imply a limitation to a data flow direction.
  • the terminal device 300 is configured to obtain or determine correlation information 103 between the at least two network slices 102 and/or sessions 105.
  • the terminal device 300 can then send the correlation information 103 to a RAN device or a CN device, which may be the RAN device 100 shown in FIG. 1 and/or the CN device 200 shown in FIG. 2.
  • Sending the correlation information to a CN device can be through a RAN device, e.g., via NAS procedures. Additionally or alternatively, the terminal device 300 can then perform a joint QoS treatment 104 for the at least two network slices 102 and/or sessions 105 based on the correlation information 103. In this way, the terminal device 100 supports multi slice services or applications in an improved manner, at least by providing correlation information 103 that can be used for joint QoS treatment 104 the RAN device 100 and/or CN device 200, or by even performing a joint QoS treatment 104 itself. The correlation information 103 can be used to determine further correlation information by the CN device.
  • FIG. 4 shows a method 400 according to an embodiment of the present invention, particularly a method 400 for implementing a correlated QoS treatment for multi-slice support of services or applications.
  • the method 400 may be used for providing at least two network slices 102 and/or at least to sessions 105 of a network slice 102 for an application or service.
  • the method 400 may, for example, be carried out by the RAN device 100 shown in FIG. 1.
  • the method 400 comprises a step 401 of obtaining or determining correlation information 103 between the at least two network slices 102 and/or at least two sessions 105 of a network slice 102.
  • the method 400 further comprises a step 402 of performing a joint QoS treatment 104 for the at least two network slices 102 and/or the at least two sessions 105 based on the correlation information 103.
  • the joint QoS treatment 104 can be implemented into a network architecture for achieving improved support for multi-slice applications or services.
  • the joint QoS treatment 104 can thereby be performed on three levels:
  • the correlation information 103 may be identified on a session 105 level, particularly a PDU session level. All QoS flows belonging to the identified sessions 105 of different network slices 102 for the same application or service may be marked correlated, and QoS parameters may be adjusted accordingly based on the correlation information 103.
  • the correlation information 103 may be identified on a QoS flow level. Only identified QoS flows belonging to sessions 105 of different network slices 102 for the same application or service may be marked correlated, and QoS parameters may be adjusted accordingly based on the correlation information 103.
  • the correlation information 103 may be identified on a packet (sequence) level. Only identified packets or packet sequences of QoS flows belonging to sessions 105 of different network slices 102 for the same application or service may be marked correlated, and QoS parameters may be adjusted accordingly based on the correlation information 103.
  • the correlated QoS treatment 104 based on the correlation information 103 can include one or more of the following:
  • ARP Allocation and Retention Priority
  • a prioritization by the terminal device 300 e.g. UE
  • packets of the correlated QoS flows 102 on the UL traffic prioritization
  • FIG. 5 shows an example of a joint QoS treatment 104 considering a session level correlation by a RAN device 100 and/or CN device 200 (as in FIG. 1 or FIG. 2) according to embodiments of the present invention.
  • the RAN device 100 is here exemplarily a gNB 100
  • the CN device 200 is exemplarily referred to as 5GC 200
  • the terminal device 101 is exemplarily a UE 101.
  • the correlation information 103 can in particular be determined on a PDU session level. At least a part of the following steps may be performed:
  • either the UE 101 can explicitly send the request for the correlated QoS treatment 104 as part of a service request to the network (5GC 200) or the 5GC 200 can determine correlation information 103. Including the correlated QoS treatment request in the non-access stratum (NAS) service request by the UE 101 is optional but possible.
  • the 5GC 200 can also make use of the correlated QoS request to identify the correlation information 103.
  • a N2 PDU session Request is provided from the 5GC 200 to the gNB 100 and contains details on correlated PDU session IDs as part of the correlation information 103.
  • the gNB 100 receives the knowledge of the correlated PDU sessions 105, and QoS flows belonging to these correlated PDU sessions 105 are modified such that gNB 100 considers, for example, a joint delay budget (e.g. on UL and DL QoS flows) and/or a joint admission control procedure, such as ARP.
  • Joint ARP handling can include priority and pre-emption capability/vulnerability.
  • Data radio bearer (DRB) parameters can also be adjusted, e.g. as described for the NG-RAN execution further below.
  • the gNB 100 can provide correlated DRB parameters to UE along with the information on the correlated PDU sessions, e.g., the joint delay budget for DL and UL transmissions with corresponding correlated PDU session IDs.
  • the UE 101 can establish the correlated DRBs and mark QoS flows belonging to the correlated PDU sessions 105.
  • Joint delay budget can be considered, e.g. in packet queuing.
  • FIG. 6 shows an example of a joint QoS treatment 104 considering a QoS flow level correlation by a RAN device 100 and/or CN device 200 (as in FIG. 1 and FIG. 2) according to embodiments of the present invention.
  • the RAN device 100 is here a gNB 100
  • the CN device 200 is referred to as 5GC 200
  • the terminal device 101 is a UE 101.
  • the correlation information 103 can be determined on a QoS flow level. To this end, at least a part of the following steps can be performed:
  • either the UE 101 can explicitly send the request for the correlated QoS treatment 104 as part of a service request to the network (5GC 200) or the 5GC 200 can determine correlation information 103. Including the correlated QoS treatment request in the non-access stratum (NAS) service request by the UE 101 is optional but possible.
  • the 5GC 200 can also make use of the correlated QoS request to identify the correlation information 103.
  • a N2 PDU session Request sent from the 5GC 200 to the gNB 100 may contain details on the correlated QoS Flow IDs (QFIs) as part of the correlation information 103.
  • QFIs QoS Flow IDs
  • the gNB 100 receives the knowledge of the correlated QoS Flows, and these particular correlated QoS flows are modified such that the gNB 100 considers, for example, a joint delay budget (e.g. on UL and DL QoS flows) and/or a joint admission control procedure, such as ARP.
  • Joint ARP handling can include priority and pre-emption capability/vulnerability.
  • DRB parameters can also be adjusted, e.g. as described for the NG-RAN execution further below.
  • the gNB 100 can provide correlated DRB parameters to the UE 101 along with the information on the correlated QoS Flows, e.g. the joint delay budget for DL and UL transmissions with corresponding correlated QFIs.
  • the UE 101 can establish the correlated DRBs and mark correlated QoS flows. Joint delay budget can be considered, e.g. in packet queuing.
  • FIG. 7 shows an example of a correlated QoS treatment 104 considering a packet (sequence) level correlation by a RAN device 100 and/or CN device 200 (as in FIG. 1 or FIG. 2) according to embodiments of the present invention.
  • the RAN device 100 is here a gNB 100
  • the CN device 200 is referred to as 5GC 200
  • the terminal device 101 is a UE 101.
  • the correlation information 103 can be determined on a packet level. To this end, at least a part of the following steps can be performed:
  • the 5GC 200 optionally with support from an application server, identifies that certain packet sequences are correlated in QoS flows of one slice 102 with other QoS flows in the another slice 102 or slices 102.
  • the packet sequences can be identified by start and end markers.
  • the packet sequences can be also identified with IDs, if available. Correlation among QoS flows and (PDU) sessions 105 can also be included.
  • a N2 PDU session Request sent from the 5GC 200 to the gNB 100 may contain details on the start and end markers and/or time stamps with information on the correlated QFIs as part of the correlation information 103.
  • the gNB 100 receives the knowledge of the correlated QoS Flows, PDU sessions 105, and packet sequences, and these particular correlated QoS flows are modified such that the gNB 100 considers, for example, a joint delay budget (e.g. on UF and DF QoS flows) for identified packet sequences and/or a joint admission control procedure, such as ARP.
  • Joint ARP handling can include priority and pre-emption capability/vulnerability.
  • DRB parameters can also be adjusted, e.g. as described for the NG-RAN execution further below.
  • the gNB 100 can provide correlated DRB parameters to the UE 101 along with the information on the correlated QoS Flows, e.g. the joint delay budget for DF and UF transmissions with corresponding correlated QFIs.
  • the UE 101 can establish the correlated DRBs and mark correlated QoS flows. Joint delay budget can be considered, e.g. in packet queuing.
  • the 5GC 200 may determine a correlation release with the support of the application layer.
  • FIG. 8 shows an example of dynamic QoS handling/adjustment by a CN device 200 according to an embodiment of the present invention.
  • the CN device 200 is here a 5GC 200
  • the RAN device 100 is a gNB 100
  • the terminal device 101 is a UE 101.
  • the QoS parameters e.g. QoS profiles and QoS Rules
  • An example modification can be a modification of ARP and delay budgets.
  • correlation information - as described above with respect to FIGs. 5-7 - can also be sent to the gNB 100 and the UE 101.
  • the gNB 100 can still perform part of the correlated QoS treatment 104, such as QoS flow synchronization.
  • the 5GC modification can be enhanced by feedback ffom NG-RAN, e.g. resource usage or contention indication.
  • FIGs. 5-8 can be combined and can be combined with the implementation shown with respect to FIG. 9 below, in in order to e.g. achieve a hybrid solution with modifications both at the 5GC 200 and the NG- RAN.
  • FIG. 9 shows an example of a NG-RAN execution for a correlated QoS treatment 104 performed e.g. by a RAN device 100 (NG-RAN device) according to an embodiment of the present invention.
  • the correlation information 103 known at the DRB level can be utilized to manage scheduling decisions at the RAN for different levels of correlations.
  • An Access Stratum (AS)-level mapping table may tell about the correlated QoS flow mapping to DRBs:
  • the FCH prioritization procedure can map correlated QoS flows to corresponding numerology sets as shown FIG. 9.
  • FIG. 10 shows an example of scheduling for performing a correlated QoS treatment 104, particularly a joint delay budget handling in case of the same link, on UF.
  • a Tele-Operator Driving (ToD) application in UF video and haptic information from a vehicle need to be synchronized.
  • Scheduling/HARQ period the URFFC slice 102 is mini slot (e.g., 2, 4 or 7 OFDM symbols), while that of the eMBB slice 102 is of 1 ms transmission time interval (TTI).
  • TTI transmission time interval
  • the latency constraint of haptic information (which is an URFFC service) can be relaxed to be synchronized with eMBB scheduling intervals.
  • FIG. 11 shows an example of scheduling for performing a correlated QoS treatment 104, particularly end-to-end (e2e) joint delay budget handling in case of different links, on UL and DL.
  • QoS flows of DF and UF are correlated to meet the QoS requirements.
  • a scheduler with the knowledge of DF/UF correlation can schedule DF traffic according to the UF information such that it meets the e2e latency constraints.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The present invention relates to the field of network slicing, as e.g. implemented in 5G. In particular, the present invention is for multi-slice service or application support. The present invention provides a RAN device for providing multiple network slices and/or sessions for a service or application. The RAN device is configured to obtain correlation information between the at least two network slices and/or at least two sessions of a network slice, and to perform a joint QoS treatment for the at least two network slices and/or the at least two sessions based on the correlation information. The present invention also provides a CN device for providing a terminal device with at least two network slices and/or sessions for an application or service. The CN device is configured to determine correlation information between the at least two network slices and/or sessions, and provide the correlation information to the RAN device.

Description

RAN DEVICE AND CORE NETWORK DEVICE FOR NETWORK SLICING
TECHNICAL FIELD
The present invention relates to the field of network slicing, as e.g. implemented in fifth generation (5G) mobile and wireless communications system. The present invention provides a Radio Access Network (RAN) device for providing/supporting multiple network slices and/or sessions for a service or application. The present invention also provides a Core Network (CN) device for providing/supporting multiple network slices and/or sessions for an application or service. In particular, the RAN and CN devices are able to perform a joint Quality of Service (QoS) treatment on the multiple slices and/or sessions, in order to improve the support for multi-slice services or applications.
BACKGROUND
The network slicing concept is introduced in 5G to address the various requirements, particularly from multiple vertical industries assuming a shared network infrastructure. Network services can be customized based on the requirements of different use cases, and thus can increase the network operation efficiency. The 5G network will provide various types of network services over the shared infrastructure by means of the network slicing concept, wherein:
• Services can be mapped to different network slices in the network level.
• The network management system is responsible for the instantiation and management of the network slice(s) over the shared infrastructure (resources, devices, physical links, etc.).
Each network slice may be supported by tailored Network Functions (NFs), such as a User Plane Function (UPF), Session Management Function (SMF), or Access and Mobility management Function (AMF). Network slices can be assigned to dedicated sources, e.g. a spectrum or a given spectrum band can be shared by different network slices considering Service Level Agreements (SLAs) of the network slices. Network slices can be identified by slice IDs, e.g., Single Network Slice Selection Assistance Information (S-NSSAI) which comprises Slice/Service type (SST) and optionally a Slice Differentiator (SD). A slice ID can be extended or modified to identify a RAN part of a network slice and a CN part of a network slice. Within the overall system architecture of 3GPP TS 23.501 :
• User Equipments (UEs) can register to a single AMF for a set of network slices.
• UEs can simultaneously establish sessions with multiple network slices.
• Session management is handled per slice by the SMF.
• The SMF can establish/modify/teardown a session (e.g. Protocol Data Unit (PDU) session) and correspondent User Plane per slice.
• Basic network slice types are defined in 3GPP and defined as per an SST. Slice types are, for example, enhanced Mobile Broadband (eMBB), massive Machine-Type Communication (mMTC), and Ultra Reliable Low Latency Communications (URLLC). Each network SST is designed for a group of services sharing similar service requirements.
FIG. 12 shows an example scenario, in which a 5G car is associated with two network slices (i.e. the car may be referred to as a multi-slice UE), namely, URLLC and eMBB slices. In FIG. 12 a part of the 5G core NFs are shown, wherein the AMF is shared by the two network slices, and wherein the SMF and UPF are tailored for the network slices. The Data Networks (DNs) can be the same. The 5G car is connected to a RAN device, e.g. a Base Station (BS), here named as gNB (next generation Node B).
As exemplarily illustrated in FIG. 12, applications/services can use multiple network slices. In particular this means that:
• Applications belonging to the same UE might require more than one network slice type, which may imply inter-dependency among slices to fulfill the application requirements.
• Due to different PDU sessions and Radio Bearer assignments to different network slices in 5G (as e.g. in 3GPP TS 38.300), the joint application requirements may not be fulfilled. FIG. 13 illustrates an example use case, in particular the use case of remote driving, where similar data flows can also exist in case of tele-presence remote diagnosis. In this use case:
• HD video transmission requires high throughput on the uplink (UL), which is supported by the eMBB slice.
• On-vehicle sensor data transmission, as part of a haptic feedback on the UL, and vehicle control signaling on the DL require low latency and high reliability, which are supported by the URLLC slice.
• Further, for remote driving, the remote operator may require synchronized haptic feedback along with the HD video.
Another example use case is Augmented Reality (AR) / Virtual Reality (VR). In this use case, haptic feedback and video control on the Uplink (UL) - supported by the URLLC slice - and segmented video data on the Downlink (DL) - supported by the eMBB slice - can be required.
So far, in 3GPP the following support for network slicing is implemented:
• A PDU session belongs to one and only one specific network slice instance per Public Land Mobile Network (PLMN). Different network slice instances do not share a PDU session (see e.g. 3GPP TS 23.501).
• The Next Generation (NG)-RAN maps packets belonging to different PDU sessions to different Data Radio Bearers (DRBs). Hence, the NG-RAN establishes at least one default DRB for each PDU session indicated by the 5G Core Network (5GC) upon PDU session establishment (see e.g. RAN2 TS 38.300).
An example multi-slice UE support considering the current implementation of network slicing is illustrated in FIG. 14. When applications are associated with multiple network slices, an independent QoS flow treatment is applied. This QoS flow treatment, however, is suboptimal for many use cases, and the application requirements may thus not be fulfilled. SUMMARY
In view of the above-mentioned shortcomings, the present invention aims to improve the current implementation for network slicing. The present invention has the objective to provide improved multi-slice service or application support. In particular, the present invention has the goal that the service or application requirements are fulfilled also in cases where an application or service is associated with multiple network slices. One intention is to enable a dependent (i.e. a joint) QoS treatment of different network slices for the same application or service. To this end, the present invention aims also for utilizing an identified correlation between different network slices. Various aspects provided herein can be applied to the case when a service or application is supported by at least two sessions or data flows within a network slice.
The objective of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.
Notably, the current implementations do not support any efficient cross slice optimization/ inter-slice coordination.
The present invention proposes a correlated QoS treatment considering that correlation(s) exists between service requirements of different network slices for the same application or service. In particular, the performance of one network slice affects the required key performance indicator (KPI) of another correlated network slice. For example, this is the case in remote driving, AR/VR, e.g. long latency of video control (direction of view).
On this basis, inter-dependency between network slices can be reflected by translating the individual KPI requirement of each network slice into one or more joint KPIs e.g. by analyzing the service request from each network slice. Such joint KPIs can be shared to the next generation - RAN (NG-RAN) from the 5G core (5GC) and/or 5G management system, e.g. by the Network Slice Management Function (NSMF) and the Network Slice Subnet Management Function (NSSMF). For instance: • The NSMF may split end-to-end (e2e) KPIs into the KPI quota in different domains (e.g. CN, RAN, and transport network-TN) and can send it to the NSSMF or inform the NSSMF of the KPI correlation between associated (correlated) network slices.
• The domain specific cross-slice management and orchestration in the NSSMF can perform inter-slice optimization within its domain (e.g. as self-organizing network- SON procedure).
A first aspect of the present invention provides a RAN, device for providing at least one terminal device with at least two network slices and/or at least two sessions of a network slice for an application or service, the RAN device being configured to obtain correlation information between the at least two network slices and/or at least two sessions of a network slice, and perform a joint Quality of Service, QoS, treatment for the at least two network slices and/or the at least two sessions based on the correlation information.
Providing not necessarily means that the slices are instantiated by the RAN. It can also mean that the slices are influenced by the RAN, i.e. managed or supported by the RAN. As network slice is end-to-end, providing a network slice from RAN perspective can be understood as providing a RAN part of the network slice. The RAN may thus be configured with the at least two network slices and/or sessions. By obtaining the correlation information and accordingly implementing the joint QoS treatment, improved multi-slice service or application support is provided. In particular, the service or application requirements may be fulfilled. A correlation information can include one or more identifiers, in particular for one or more slices, for one or more sessions, and/or for one or more data flows.
In an implementation form of the first aspect, the RAN device is configured to perform the joint QoS treatment by adjusting at least one QoS parameter for each of the at least two network slices and/or sessions based on the correlation information.
In a further implementation form of the first aspect, the correlation information is between a first session of a first network slice and a second session of the first network slice and/or a second network slice, and the RAN device is configured to adjust at least one QoS parameter of each QoS flow belonging to the first session and each QoS flow belonging to the second session, respectively, based on the correlation information. Thus, the correlation information is obtained on a session level, and the joint QoS treatment is performed accordingly on sessions.
In a further implementation form of the first aspect, the correlation information is between a first QoS flow belonging to a session of a first network slice and a second QoS flow belonging to a session of the first network slice and/or a second network slice, and the RAN device is configured to adjust at least one QoS parameter of the first QoS flow and the second QoS flow, respectively, based on the correlation information.
Thus, the correlation information is obtained on a QoS flow level, and the joint QoS treatment is performed accordingly on QoS flows. This can provide a finer granularity than joint QoS treatment on sessions.
In a further implementation form of the first aspect, the correlation information is between a first packet sequence of a QoS flow belonging to a session of a first network slice and a second packet sequence of a QoS flow belonging to a session of the first network slice and/or a second network slice, and the RAN device is configured to adjust at least one QoS parameter of the first packet sequence and the second packet sequence, respectively, based on the correlation information.
A packet sequence can be at least one packet. Thus, the correlation information is obtained on a packet sequence level, and the joint QoS treatment is performed accordingly on packet sequences of QoS flows. This provides an even finer granularity than joint QoS treatment on QoS flows.
In a further implementation form of the first aspect, the joint QoS treatment includes at least one of: joint allocating and/or scheduling of radio resources; adapting a joint Key Performance Indicator, KPI; considering a joint Automatic Retention Policy, ARP; joint Radio Resource Management, RRM; selecting a joint packet delay budget; modifying QoS profiles and QoS rules of the correlated QoS flows; QoS flow synchronization of the correlated QoS flows; QoS flow prioritization for correlated QoS flows; logical channel prioritization and medium access control (MAC) reconfiguration; radio bearer modification. Further, the joint QoS treatment may also include joint admission control. In addition, logical channel prioritization in RAN can take care of joint delay budget, e.g., packet delay budget (PDB), joint numerology configuration as part of logical channel restrictions and radio bearer configuration for joint QoS treatment. In this manner, the multi-slice user support can be significantly improved, particularly in terms of network efficiency and meeting all service or application requirements.
In a further implementation form of the first aspect, the joint QoS treatment includes prioritizing correlated QoS flows or correlated packet sequences of QoS flows over non- correlated QoS flows or packet sequences of QoS flows, respectively, based on the correlation information.
Thus, multi-slice services or applications are better supported.
In a further implementation form of the first aspect, the RAN device is configured to receive the correlation information from a Core Network, CN, device, and/or provide the correlation information to the terminal device.
In this way, the correlation information is exposed throughout the network architecture, in order to enable optimization of multi-slice service or application support. The transmission of the correlation information to the terminal device can be performed via non-access stratum (NAS) procedures, e.g., via Nl interface.
A second aspect of the present invention provides a CN device for providing a terminal device with at least two network slices and/or at least two sessions of a network slice for an application or service, the CN device being configured to determine correlation information between the at least two network slices and/or sessions, and provide the correlation information to a RAN device.
The RAN device may, for instance, be the RAN device of the first aspect. The CN device can include 5G core network functions, such as AMF, SMF and UPF. By determining and exposing the correlation information by the CN device, multi-slice services or applications can be better supported. For example, the RAN device may perform the joint QoS treatment based on the correlation information as described above. In an implementation form of the second aspect, the CN device is configured to determine the correlation information between sessions of the at least two network slices.
In particular, the CN device may determine the correlation information between a first session of a first network slice and a second session of the first network slice and/or a second network slice. Thus, the correlation information is determined on a session level.
In a further implementation form of the second aspect, the CN device is configured to determine the correlation information between QoS flows belonging to sessions of the at least two network slices.
In particular, the CN device may determine the correlation information between a first QoS flow belonging to a session of a first network slice and a second QoS flow belonging to a session of the first network slice and/or a second network slice. Thus, the correlation information is obtained on a QoS flow level. This provides a finer granularity than the determination on the session level.
In a further implementation form of the second aspect, the CN device is configured to determine the correlation information between packet sequences of QoS flows belonging to sessions of the at least two network slices.
In particular, the CN device may determine the correlation information between a first packet sequence of a QoS flow belonging to a session of a first network slice and a second packet sequence of a QoS flow belonging to a session of the first network slice and/or a second network slice. A packet sequence may be at least one packet. Thus, the correlation information is obtained on a packet level. This provides an even finer granularity than the determination on the QoS flow level.
In a further implementation form of the second aspect, the correlation information comprises at least one of: a correlation between service requirements of the at least two network slices and/or sessions for the service or application; a correlation between performances of the at least two network slices and/or sessions for the service or application; a shared latency budget between the at least two network slices and/or sessions for the service or application.
By determining and exposing such correlation information by the CN device, the service requirements of different network slices for the same application or service can be better fulfilled. Further, the performance can be improved. Further, the performance can be also a predicted or estimated performance.
In a further implementation form of the second aspect, the CN device is configured to receive a request for joint QoS treatment from the terminal device, and determine the correlation information based on the received request.
This can provide a straightforward implementation, where the joint QoS treatment is triggered by the user. Further, the information provided in the request by user can be used to determine correlation information by the CN device. Such information may be provided by an application of the user and/or as part of NAS service request from the user. The request for joint QoS treatment can include a request for specific QoS handling, e.g., a correlation indication for selected service data flow(s) (SDFs), and Packet Filters describing the SDF(s). Such correlation indication can be used by the CN device to bind the applicable SDF(s) on QoS Flows.
In a further implementation form of the second aspect, the CN device is configured to perform a joint QoS treatment for the at least two network slices and/or sessions based on the correlation information.
For instance, QoS parameters like QoS profiles and QoS Rules can be modified by the CN device to abide by the joint requirements. Thus, the support for multi-slice services or applications is further improved.
A third aspect of the present invention provides a terminal device for using at least two network slices and/or at least two sessions of a network slice for an application or service, the terminal device being configured to obtain or determine correlation information between the at least two network slices and/or sessions, and transmit the correlation information to a RAN or a CN-device; and/or perform a joint QoS treatment for the at least two network slices and/or sessions based on the correlation information.
The terminal device supports multi-slice services or applications in an improved manner. In particular, it can support the optimization of the throughput, and network efficiency, and the meeting of the service or application requirements.
In an implementation form of the third aspect, the terminal device is configured to receive further correlation information from a RAN or a CN device; and perform a joint QoS treatment for the at least two network slices and/or sessions based on the further correlation information.
Thus, different types or levels of correlation information can be obtained, for instance, at the terminal device and the RAN or CN device, respectively. The joint QoS treatment can thus be optimized.
A fourth aspect of the present invention provides a method for providing at least two network slices and/or at least two sessions of a network slice for an application or service, the method comprising obtaining or determining correlation information between the at least two network slices and/or at least two sessions of a network slice, and performing a joint Quality of Service, QoS, treatment for the at least two network slices and/or the at least two sessions based on the correlation information.
In an implementation form of the fourth aspect, the method comprises performing the joint QoS treatment by adjusting at least one QoS parameter for each of the at least two network slices and/or sessions based on the correlation information.
In a further implementation form of the fourth aspect, the correlation information is between a first session of a first network slice and a second session of the first network slice and/or a second network slice, and the method comprises adjusting at least one QoS parameter of each QoS flow belonging to the first session and each QoS flow belonging to the second session, respectively, based on the correlation information. In a further implementation form of the fourth aspect, the correlation information is between a first QoS flow belonging to a session of a first network slice and a second QoS flow belonging to a session of the first network slice and/or a second network slice, and the method comprises adjusting at least one QoS parameter of the first QoS flow and the second QoS flow, respectively, based on the correlation information.
In a further implementation form of the fourth aspect, the correlation information is between a first packet sequence of a QoS flow belonging to a session of a first network slice and a second packet sequence of a QoS flow belonging to a session of the first network slice and/or a second network slice, and the method comprises adjusting at least one QoS parameter of the first packet sequence and the second packet sequence, respectively, based on the correlation information.
In a further implementation form of the fourth aspect, the joint QoS treatment includes at least one of: joint allocating and/or scheduling of radio resources; adapting a joint Key Performance Indicator, KPI; considering a joint Automatic Retention Policy, ARP; joint Radio Resource Management, RRM; selecting a joint packet delay budget; modifying QoS profiles and QoS rules of the correlated QoS flows; QoS flow synchronization of the correlated QoS flows; QoS flow prioritization for correlated QoS flows; logical channel prioritization and MAC reconfiguration; radio bearer modification.
In a further implementation form of the fourth aspect, the joint QoS treatment includes prioritizing correlated QoS flows or correlated packet sequences of QoS flows over non- correlated QoS flows or packet sequences of QoS flows, respectively, based on the correlation information.
In a further implementation form of the fourth aspect, the method comprises receiving the correlation information from a CN device, and/or providing the correlation information to the terminal device.
The method of the fourth aspect and its implementation forms achieve the same advantages and effects as described above for the previous aspects and implementation forms, particularly of the RAN device of the first aspect. It has to be noted that the joint QoS treatment can be performed on different granularities, e.g., between QoS flow and packet sequence.
It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.
BRIEF DESCRIPTION OF DRAWINGS
The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which
FIG. 1 shows a RAN device according to an embodiment of the present invention.
FIG. 2 shows a CN device according to an embodiment of the present invention.
FIG. 3 shows a terminal device according to an embodiment of the present invention.
FIG. 4 shows a method for correlated QoS treatment according to an embodiment of the present invention.
FIG. 5 shows an example of a correlated QoS treatment considering a PDU session- level correlation by a RAN or CN device according to an embodiment of the present invention. FIG. 6 shows an example of correlated QoS treatment considering QoS flow-level correlation by a RAN or CN device according to an embodiment of the present invention.
FIG. 7 shows an example of correlated QoS treatment considering a Packet
Sequence- level correlation by a RAN or CN device according to an embodiment of the present invention.
FIG. 8 shows an example of dynamic QoS adjustment by a CN device according to an embodiment of the present invention.
FIG. 9 shows an example of a NG-RAN execution for a correlated QoS treatment by a RAN device according to an embodiment of the present invention.
FIG. 10 shows an example of scheduling for a correlated QoS treatment on UL.
FIG. 11 shows an example of scheduling for correlated QoS treatment on UL and
DL.
FIG. 12 shows an exemplary illustration of a multi-slice terminal device (UE).
FIG. 13 shows an example of a use case for remote driving.
FIG. 14 shows an example of conventional multi-slice UE support with different
PDU sessions.
DETAILED DESCRIPTION OF EMBODIMENTS
FIG. 1 shows a RAN device 100 according to an embodiment of the present invention. The RAN device 100 is configured to provide at least one terminal device 101 with at least two network slices 102 and/or at least two sessions 105 of a network slice 102 for an application or service. The directions of the arrows do not imply a limitation to a data flow direction, i.e., data flows can be on the downlink and/or uplink.
Thereby, the RAN device 100 is configured to obtain correlation information 103 between the at least two network slices 102 and/or at least two sessions 105 of a network slice 102. Then, the RAN device 100 is configured to perform a joint QoS treatment 104 for the at least two network slices 102 and/or the at least two sessions 105 based on the correlation information 103. Due to the joint QoS treatment, the service or application using the at least two network slices 102 or sessions 105 can be better supported. In particular, all service or application requirements for the different slices 102 or sessions 105 can be met.
FIG. 2 shows a CN device 200 according to an embodiment of the present invention. In particular, the CN device 200 is configured to provide a terminal device 101 with at least two network slices 102 and/or at least two sessions 105 of a network slice (not explicitly shown) for an application or service. Again, the directions of the arrows do not imply a limitation to a data flow direction.
Thereby, the CN device 200 is configured to determine correlation information 103 between the at least two network slices 102 and/or sessions, and to provide the determined correlation information 103 to a RAN device. The RAN device may be the RAN device 100 shown in FIG. 1. Thus, by determining and providing the correlation information 103 by the CN device 200, the RAN device 100 is enabled to perform the joint QoS treatment 104 for the at least two network slices 102 and/or sessions 105. Accordingly, the CN device 200 supports the service or application using the different network slices 102 and/or sessions 105.
FIG. 3 shows a terminal device 300 according to an embodiment of the present invention. The terminal device 300 is configured to use at least two network slices 102 and/or at least two sessions 105 (not explicitly shown) of a network slice 102 for an application or service. The terminal device 300 may be the terminal device 101 shown in FIG. 1 and FIG. 2, respectively. Again, the directions of the arrows do not imply a limitation to a data flow direction. The terminal device 300 is configured to obtain or determine correlation information 103 between the at least two network slices 102 and/or sessions 105. The terminal device 300 can then send the correlation information 103 to a RAN device or a CN device, which may be the RAN device 100 shown in FIG. 1 and/or the CN device 200 shown in FIG. 2. Sending the correlation information to a CN device can be through a RAN device, e.g., via NAS procedures. Additionally or alternatively, the terminal device 300 can then perform a joint QoS treatment 104 for the at least two network slices 102 and/or sessions 105 based on the correlation information 103. In this way, the terminal device 100 supports multi slice services or applications in an improved manner, at least by providing correlation information 103 that can be used for joint QoS treatment 104 the RAN device 100 and/or CN device 200, or by even performing a joint QoS treatment 104 itself. The correlation information 103 can be used to determine further correlation information by the CN device.
FIG. 4 shows a method 400 according to an embodiment of the present invention, particularly a method 400 for implementing a correlated QoS treatment for multi-slice support of services or applications. The method 400 may be used for providing at least two network slices 102 and/or at least to sessions 105 of a network slice 102 for an application or service. The method 400 may, for example, be carried out by the RAN device 100 shown in FIG. 1.
The method 400 comprises a step 401 of obtaining or determining correlation information 103 between the at least two network slices 102 and/or at least two sessions 105 of a network slice 102. The method 400 further comprises a step 402 of performing a joint QoS treatment 104 for the at least two network slices 102 and/or the at least two sessions 105 based on the correlation information 103.
By means of the RAN device 100, the CN device 200, the terminal device 300, and/or the method 400 according to the embodiments of the present invention described above, the joint QoS treatment 104 can be implemented into a network architecture for achieving improved support for multi-slice applications or services. The joint QoS treatment 104 can thereby be performed on three levels:
For a“PDU Session Level Correlation”, the correlation information 103 may be identified on a session 105 level, particularly a PDU session level. All QoS flows belonging to the identified sessions 105 of different network slices 102 for the same application or service may be marked correlated, and QoS parameters may be adjusted accordingly based on the correlation information 103.
• For a“QoS Flow Level Correlation”, the correlation information 103 may be identified on a QoS flow level. Only identified QoS flows belonging to sessions 105 of different network slices 102 for the same application or service may be marked correlated, and QoS parameters may be adjusted accordingly based on the correlation information 103.
• For a“Packet Sequence Level Correlation”, the correlation information 103 may be identified on a packet (sequence) level. Only identified packets or packet sequences of QoS flows belonging to sessions 105 of different network slices 102 for the same application or service may be marked correlated, and QoS parameters may be adjusted accordingly based on the correlation information 103.
In all cases, the correlated QoS treatment 104 based on the correlation information 103 can include one or more of the following:
• Correlated radio resource allocation/scheduling decisions considering joint delay budget for the correlated flows of different network slices 102 of the same UE/ application/ service .
• A new RAN configuration to adapt to joint KPIs, e.g. Packet Duplication for higher reliability and HARQ operation points.
• A prioritization by the RAN device 100 (e.g. gNB) of the correlated QoS flows over other QoS flows in the associated sessions 105 of the network slices 102 of the same UE/application/service (e.g. joint Allocation and Retention Priority (ARP) handling).
• A prioritization by the terminal device 300 (e.g. UE) of packets of the correlated QoS flows 102 on the UL (traffic prioritization).
• A logical channel prioritization to numerology mapping.
• A possible extension to multi-cast scenarios for group communications.
In the following, more detailed implementations are provided for the different levels
(session level, QoS flow level, packet sequence level) of obtaining the correlation information 103, and accordingly performing the correlated QoS treatment 104. FIG. 5 shows an example of a joint QoS treatment 104 considering a session level correlation by a RAN device 100 and/or CN device 200 (as in FIG. 1 or FIG. 2) according to embodiments of the present invention. The RAN device 100 is here exemplarily a gNB 100, the CN device 200 is exemplarily referred to as 5GC 200, and the terminal device 101 is exemplarily a UE 101.
The correlation information 103 can in particular be determined on a PDU session level. At least a part of the following steps may be performed:
1. As shown in the message sequence in FIG. 5, either the UE 101 can explicitly send the request for the correlated QoS treatment 104 as part of a service request to the network (5GC 200) or the 5GC 200 can determine correlation information 103. Including the correlated QoS treatment request in the non-access stratum (NAS) service request by the UE 101 is optional but possible. The 5GC 200 can also make use of the correlated QoS request to identify the correlation information 103.
2. A N2 PDU session Request is provided from the 5GC 200 to the gNB 100 and contains details on correlated PDU session IDs as part of the correlation information 103.
3. The gNB 100 receives the knowledge of the correlated PDU sessions 105, and QoS flows belonging to these correlated PDU sessions 105 are modified such that gNB 100 considers, for example, a joint delay budget (e.g. on UL and DL QoS flows) and/or a joint admission control procedure, such as ARP. Joint ARP handling can include priority and pre-emption capability/vulnerability. Data radio bearer (DRB) parameters can also be adjusted, e.g. as described for the NG-RAN execution further below.
4. The gNB 100 can provide correlated DRB parameters to UE along with the information on the correlated PDU sessions, e.g., the joint delay budget for DL and UL transmissions with corresponding correlated PDU session IDs.
5. The UE 101 can establish the correlated DRBs and mark QoS flows belonging to the correlated PDU sessions 105. Joint delay budget can be considered, e.g. in packet queuing.
FIG. 6 shows an example of a joint QoS treatment 104 considering a QoS flow level correlation by a RAN device 100 and/or CN device 200 (as in FIG. 1 and FIG. 2) according to embodiments of the present invention. The RAN device 100 is here a gNB 100, the CN device 200 is referred to as 5GC 200, and the terminal device 101 is a UE 101.
The correlation information 103 can be determined on a QoS flow level. To this end, at least a part of the following steps can be performed:
1. As shown in the message sequence in FIG. 6, either the UE 101 can explicitly send the request for the correlated QoS treatment 104 as part of a service request to the network (5GC 200) or the 5GC 200 can determine correlation information 103. Including the correlated QoS treatment request in the non-access stratum (NAS) service request by the UE 101 is optional but possible. The 5GC 200 can also make use of the correlated QoS request to identify the correlation information 103.
2. A N2 PDU session Request sent from the 5GC 200 to the gNB 100 may contain details on the correlated QoS Flow IDs (QFIs) as part of the correlation information 103.
3. The gNB 100 receives the knowledge of the correlated QoS Flows, and these particular correlated QoS flows are modified such that the gNB 100 considers, for example, a joint delay budget (e.g. on UL and DL QoS flows) and/or a joint admission control procedure, such as ARP. Joint ARP handling can include priority and pre-emption capability/vulnerability. DRB parameters can also be adjusted, e.g. as described for the NG-RAN execution further below.
4. The gNB 100 can provide correlated DRB parameters to the UE 101 along with the information on the correlated QoS Flows, e.g. the joint delay budget for DL and UL transmissions with corresponding correlated QFIs.
5. The UE 101 can establish the correlated DRBs and mark correlated QoS flows. Joint delay budget can be considered, e.g. in packet queuing.
FIG. 7 shows an example of a correlated QoS treatment 104 considering a packet (sequence) level correlation by a RAN device 100 and/or CN device 200 (as in FIG. 1 or FIG. 2) according to embodiments of the present invention. The RAN device 100 is here a gNB 100, the CN device 200 is referred to as 5GC 200, and the terminal device 101 is a UE 101. The correlation information 103 can be determined on a packet level. To this end, at least a part of the following steps can be performed:
1. As shown in the message sequence in FIG. 7, the 5GC 200, optionally with support from an application server, identifies that certain packet sequences are correlated in QoS flows of one slice 102 with other QoS flows in the another slice 102 or slices 102. Here, the packet sequences can be identified by start and end markers. The packet sequences can be also identified with IDs, if available. Correlation among QoS flows and (PDU) sessions 105 can also be included.
2. A N2 PDU session Request sent from the 5GC 200 to the gNB 100 may contain details on the start and end markers and/or time stamps with information on the correlated QFIs as part of the correlation information 103.
3. The gNB 100 receives the knowledge of the correlated QoS Flows, PDU sessions 105, and packet sequences, and these particular correlated QoS flows are modified such that the gNB 100 considers, for example, a joint delay budget (e.g. on UF and DF QoS flows) for identified packet sequences and/or a joint admission control procedure, such as ARP. Joint ARP handling can include priority and pre-emption capability/vulnerability. DRB parameters can also be adjusted, e.g. as described for the NG-RAN execution further below.
4. The gNB 100 can provide correlated DRB parameters to the UE 101 along with the information on the correlated QoS Flows, e.g. the joint delay budget for DF and UF transmissions with corresponding correlated QFIs.
5. The UE 101 can establish the correlated DRBs and mark correlated QoS flows. Joint delay budget can be considered, e.g. in packet queuing.
6. The 5GC 200 may determine a correlation release with the support of the application layer.
FIG. 8 shows an example of dynamic QoS handling/adjustment by a CN device 200 according to an embodiment of the present invention. The CN device 200 is here a 5GC 200, the RAN device 100 is a gNB 100, and the terminal device 101 is a UE 101.
As shown in FIG. 8, when the correlation is identified by the 5GC 200, the QoS parameters, e.g. QoS profiles and QoS Rules, can be modified by the 5GC 200 to abide by the joint requirements. An example modification can be a modification of ARP and delay budgets. In this case, correlation information - as described above with respect to FIGs. 5-7 - can also be sent to the gNB 100 and the UE 101. The gNB 100 can still perform part of the correlated QoS treatment 104, such as QoS flow synchronization. The 5GC modification can be enhanced by feedback ffom NG-RAN, e.g. resource usage or contention indication.
Furthermore, the aforementioned implementations shown in FIGs. 5-8 can be combined and can be combined with the implementation shown with respect to FIG. 9 below, in in order to e.g. achieve a hybrid solution with modifications both at the 5GC 200 and the NG- RAN.
FIG. 9 shows an example of a NG-RAN execution for a correlated QoS treatment 104 performed e.g. by a RAN device 100 (NG-RAN device) according to an embodiment of the present invention.
The correlation information 103 known at the DRB level can be utilized to manage scheduling decisions at the RAN for different levels of correlations. An Access Stratum (AS)-level mapping table may tell about the correlated QoS flow mapping to DRBs:
• All DRBs belonging to identified PDU sessions 105 of different slices 102 belonging to the same UE 101 may be marked correlated and may be informed to a Fogical Channel (FCH) prioritization procedure, which can restrict the corresponding numerology (Num) sets based on the correlated reliability and joint delay budget (DF:Numl, UF:Num2 } . This can imply modifications on the Fogical Channel Prioritization (FCP) and MAC Reconfiguration.
• The FCH prioritization procedure can map correlated QoS flows to corresponding numerology sets as shown FIG. 9.
FIG. 10 shows an example of scheduling for performing a correlated QoS treatment 104, particularly a joint delay budget handling in case of the same link, on UF. As an example, as shown in FIG. 10, in a Tele-Operator Driving (ToD) application in UF, video and haptic information from a vehicle need to be synchronized. Scheduling/HARQ period the URFFC slice 102 is mini slot (e.g., 2, 4 or 7 OFDM symbols), while that of the eMBB slice 102 is of 1 ms transmission time interval (TTI). In case of correlated QoS configuration awareness to the scheduler, the latency constraint of haptic information (which is an URFFC service) can be relaxed to be synchronized with eMBB scheduling intervals. With relaxed latency constraints known at the scheduler level, an appropriate scheduling interval to meet the joint delay budget is chosen. FIG. 11 shows an example of scheduling for performing a correlated QoS treatment 104, particularly end-to-end (e2e) joint delay budget handling in case of different links, on UL and DL. As an example, as shown in FIG 11, QoS flows of DF and UF are correlated to meet the QoS requirements. A scheduler with the knowledge of DF/UF correlation can schedule DF traffic according to the UF information such that it meets the e2e latency constraints.
The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word“comprising” does not exclude other elements or steps and the indefinite article“a” or“an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.
The project leading to this application has received funding from the European Union’s 5G-MoNArch programme under grant agreement No 761445

Claims

Claims
1. Radio Access Network, RAN, device (100) for providing at least one terminal device (101) with at least two network slices (102) and/or at least two sessions (105) of a network slice (102) for an application or service, the RAN device (100) being configured to
obtain correlation information (103) between the at least two network slices (102) and/or at least two sessions (105) of a network slice (102), and
perform a joint Quality of Service, QoS, treatment (104) for the at least two network slices (102) and/or the at least two sessions (105) based on the correlation information (103).
2. RAN device (100) according to claim 1, configured to
perform the joint QoS treatment (104) by adjusting at least one QoS parameter for each of the at least two network slices (102) and/or sessions (105) based on the correlation information (103).
3. RAN device (100) according to claim 1 or 2, wherein
the correlation information (103) is between a first session (105) of a first network slice (102) and a second session (105) of the first network slice (102) and/or a second network slice (102), and the RAN device (100) is configured to
adjust at least one QoS parameter of each QoS flow belonging to the first session (105) and each QoS flow belonging to the second session (105), respectively, based on the correlation information (103).
4. RAN device (100) according to claim 1 or 2, wherein
the correlation information (103) is between a first QoS flow belonging to a session (105) of a first network slice (102) and a second QoS flow belonging to a session (105) of the first network slice (102) and/or a second network slice (102), and the RAN device (100) is configured to
adjust at least one QoS parameter of the first QoS flow and the second QoS flow, respectively, based on the correlation information (103).
5. RAN device (100) according to claim 1 or 2, wherein
the correlation information (103) is between a first packet sequence of a QoS flow belonging to a session (105) of a first network slice (102) and a second packet sequence of a QoS flow belonging to a session (105) of the first network slice (102) and/or a second network slice (102), and the RAN device (100) is configured to
adjust at least one QoS parameter of the first packet sequence and the second packet sequence, respectively, based on the correlation information (103).
6. RAN device (100) according to one of the claims 1 to 5, wherein
the joint QoS treatment (104) includes at least one of:
joint allocating and/or scheduling of radio resources,
adapting a joint Key Performance Indicator, KPI,
considering a joint Automatic Retention Policy, ARP,
joint Radio Resource Management, RRM,
selecting a joint packet delay budget,
modifying QoS profiles and QoS rules of the correlated QoS flows,
QoS flow synchronization of the correlated QoS flows,
QoS flow prioritization for correlated QoS flows,
logical Channel Prioritization and MAC reconfiguration,
radio bearer modification.
7. RAN device (100) according to one of the claims 1 to 6, wherein
the joint QoS treatment (104) includes prioritizing correlated QoS flows or correlated packet sequences of QoS flows over non-correlated QoS flows or packet sequences of QoS flows, respectively, based on the correlation information (103).
8. RAN device (100) according to one of the claims 1 to 7, configured to
receive the correlation information (103) from a Core Network, CN, device, (200) and/or
provide the correlation information (103) to the terminal device (101).
9. Core Network, CN, device (200) for providing a terminal device (101) with at least two network slices (202) and/or at least two sessions (105) of a network slice (102) for an application or service, the CN device (200) being configured to determine correlation information (103) between the at least two network slices (102) and/or sessions (105), and
provide the correlation information (103) to a Radio Access Network, RAN, device
(100).
10. CN device (200) according to claim 9, configured to
determine the correlation information (103) between sessions (105) of the at least two network slices (102).
11. CN device (200) according to claim 9 or 10, configured to
determine the correlation information (103) between QoS flows belonging to sessions (105) of the at least two network slices (102).
12. CN device (200) according to claim 9 or 10, configured to
determine the correlation information (103) between packet sequences of QoS flows belonging to sessions (105) of the at least two network slices (102).
13. CN device (200) according to one of the claims 9 to 12, wherein
the correlation information (103) comprises at least one of:
a correlation between service requirements of the at least two network slices (102) and/or sessions (105) for the service or application,
a correlation between performances of the at least two network slices (102) and/or sessions (105) for the service or application,
a shared latency budget between the at least two network slices (102) and/or sessions (105) for the service or application.
14. CN device (200) according to one of the claims 9 to 13, configured to
receive a request for joint QoS treatment (104) from the terminal device (101), and determine the correlation information (103) based on the received request.
15. CN device (200) according to one of the claims 9 to 14, configured to
perform a joint QoS treatment (104) for the at least two network slices (102) and/or sessions (105) based on the correlation information (105).
16. Terminal device (300) for using at least two network slices (102) and/or at least two sessions (105) of a network slice (102) for an application or service, the terminal device (300) being configured to
obtain or determine correlation information (103) between the at least two network slices (102) and/or sessions (105), and
transmit the correlation information (103) to a RAN (100) or a CN-device (200); and/or
perform a joint Quality of Service, QoS, treatment (104) for the at least two network slices (102) and/or sessions based on the correlation information (103).
17. Terminal device (300) according to the preceding claim configured to
receive further correlation information from a RAN (100) or a CN device (200); and
perform a joint Quality of Service, QoS, treatment (104) for the at least two network slices (102) and/or sessions (105) based on the further correlation information.
18. Method (400) for providing at least two network slices (102) and/or at least two sessions (105) of a network slice (102) for an application or service, the method (400) comprising
obtaining (401) or determining correlation information (103) between the at least two network slices (102) and/or at least two sessions (105) of a network slice (102), and performing (402) a joint Quality of Service, QoS, treatment (104) for the at least two network slices (102) and/or the at least two sessions (105) based on the correlation information (103).
PCT/EP2018/054037 2018-02-19 2018-02-19 Ran device and core network device for network slicing Ceased WO2019158219A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2018/054037 WO2019158219A1 (en) 2018-02-19 2018-02-19 Ran device and core network device for network slicing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2018/054037 WO2019158219A1 (en) 2018-02-19 2018-02-19 Ran device and core network device for network slicing

Publications (1)

Publication Number Publication Date
WO2019158219A1 true WO2019158219A1 (en) 2019-08-22

Family

ID=61274241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/054037 Ceased WO2019158219A1 (en) 2018-02-19 2018-02-19 Ran device and core network device for network slicing

Country Status (1)

Country Link
WO (1) WO2019158219A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021136636A1 (en) * 2020-01-03 2021-07-08 Nokia Technologies Oy Grouping qos flow for user equipment to user equipment communications
WO2022051970A1 (en) * 2020-09-10 2022-03-17 Qualcomm Incorporated Quality of service flow for communications
CN114586324A (en) * 2019-10-08 2022-06-03 高通股份有限公司 System and apparatus providing network assistance for traffic processing in downlink streaming
EP4118795A1 (en) * 2020-03-11 2023-01-18 Telefonaktiebolaget LM Ericsson (publ) Network packet handling
US11601947B2 (en) * 2020-08-17 2023-03-07 Verizon Patent And Licensing Inc. Systems and methods for network slice selection according to application specific request
WO2023088155A1 (en) * 2021-11-19 2023-05-25 华为技术有限公司 Quality-of-service (qos) management method and apparatus
WO2023123401A1 (en) 2021-12-31 2023-07-06 Zte Corporation Method for data traffic correlation and transmission
EP4138439A4 (en) * 2020-05-15 2023-09-06 Huawei Technologies Co., Ltd. Communication method, apparatus, and system
WO2025050402A1 (en) * 2023-09-08 2025-03-13 Nokia Shanghai Bell Co., Ltd. Resource management
WO2025058657A1 (en) * 2023-09-13 2025-03-20 Dell Products, L.P. Relative quality of service adaptation of bi-directional multi-mode traffic
WO2025168664A1 (en) * 2024-02-07 2025-08-14 Telefonaktiebolaget Lm Ericsson (Publ) Technique for handling multi-modal pdu sets

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170257870A1 (en) * 2016-03-04 2017-09-07 Huawei Technologies Co., Ltd. Systems and methods for performing traffic engineering through network slices
US20180014222A1 (en) * 2016-07-05 2018-01-11 Electronics And Telecommunications Research Institute COMMUNICATION METHOD AND APPARATUS BASED ON QUALITY OF SERVICE (QoS) IN NETWORK SLICE-BASED MOBILE COMMUNICATION NETWORK
CN107690159A (en) * 2016-08-05 2018-02-13 电信科学技术研究院 The processing method and processing device of user face data

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170257870A1 (en) * 2016-03-04 2017-09-07 Huawei Technologies Co., Ltd. Systems and methods for performing traffic engineering through network slices
US20180014222A1 (en) * 2016-07-05 2018-01-11 Electronics And Telecommunications Research Institute COMMUNICATION METHOD AND APPARATUS BASED ON QUALITY OF SERVICE (QoS) IN NETWORK SLICE-BASED MOBILE COMMUNICATION NETWORK
CN107690159A (en) * 2016-08-05 2018-02-13 电信科学技术研究院 The processing method and processing device of user face data

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114586324A (en) * 2019-10-08 2022-06-03 高通股份有限公司 System and apparatus providing network assistance for traffic processing in downlink streaming
CN114586324B (en) * 2019-10-08 2024-01-12 高通股份有限公司 A method, device and storage medium for providing services from a network
WO2021136636A1 (en) * 2020-01-03 2021-07-08 Nokia Technologies Oy Grouping qos flow for user equipment to user equipment communications
US12301474B2 (en) 2020-03-11 2025-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Network packet handling
EP4118795A1 (en) * 2020-03-11 2023-01-18 Telefonaktiebolaget LM Ericsson (publ) Network packet handling
EP4138439A4 (en) * 2020-05-15 2023-09-06 Huawei Technologies Co., Ltd. Communication method, apparatus, and system
US11601947B2 (en) * 2020-08-17 2023-03-07 Verizon Patent And Licensing Inc. Systems and methods for network slice selection according to application specific request
WO2022051970A1 (en) * 2020-09-10 2022-03-17 Qualcomm Incorporated Quality of service flow for communications
WO2023088155A1 (en) * 2021-11-19 2023-05-25 华为技术有限公司 Quality-of-service (qos) management method and apparatus
WO2023123401A1 (en) 2021-12-31 2023-07-06 Zte Corporation Method for data traffic correlation and transmission
EP4381785A4 (en) * 2021-12-31 2025-02-26 ZTE Corporation METHOD FOR CORRELATION AND TRANSMISSION OF DATA TRAFFIC
JP2025501041A (en) * 2021-12-31 2025-01-17 中興通訊股▲ふん▼有限公司 Method for data traffic correlation and transmission
WO2025050402A1 (en) * 2023-09-08 2025-03-13 Nokia Shanghai Bell Co., Ltd. Resource management
WO2025058657A1 (en) * 2023-09-13 2025-03-20 Dell Products, L.P. Relative quality of service adaptation of bi-directional multi-mode traffic
WO2025168664A1 (en) * 2024-02-07 2025-08-14 Telefonaktiebolaget Lm Ericsson (Publ) Technique for handling multi-modal pdu sets

Similar Documents

Publication Publication Date Title
US12028264B2 (en) Support of quality of service for V2X transmissions
US11968649B2 (en) Resource allocation method and device for supporting vehicle communication in next generation mobile communication system
WO2019158219A1 (en) Ran device and core network device for network slicing
US11051275B2 (en) Semi-persistent resource allocation behavior for V2X transmissions
US20190053251A1 (en) Priority-optimized sidelink data transfer in the case of autonomous resource allocation in lte prose communication
EP4052503B1 (en) Method and apparatus for supporting fully-distributed time-sensitive networking in mobile communication system
CN110249690A (en) In a wireless communication system by the terminal of the V2X terminal V2X communication means executed and use this method
AU2005286172B2 (en) Resource allocation in a communication system
EP3912388B1 (en) Infrastructure equipment, wireless communications networks and methods
RU2772319C2 (en) Method for resource distribution and device for supporting vehicle communication in the next generation mobile communication system
CN119948934A (en) Wireless communication method, network element and device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18706995

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18706995

Country of ref document: EP

Kind code of ref document: A1