Obtaining and providing assistance information to radio access network

Abstract

A session management function (SMF) transmits, to a user plane function (UPF), traffic periodicity information. The SMF receives, from the UPF, jitter information obtained by the UPF based on the traffic periodicity information and a packet delay measurement performed by the UPF. The SMF transmits the jitter and traffic periodicity information to a radio access network (RAN) as RAN assistance information e.g. as Time Sensitive Communication Assistance Information (TSCAI). The jitter and traffic periodicity information are for configuring a Connected Mode Discontinuous Reception (CDRX) procedure. The jitter information may be N6 jitter information; the jitter information and the traffic periodicity information may relate to Extended Reality and Media (XRM) services.

Description

BACKGROUND Field Certain examples of the present disclosure provide various techniques relating to extended reality (XR) and and media traffic specific information, namely, jitter and periodicity information by providing jitter and periodicity measurement collection procedure and procedures on how to provide the information to a radio access network (RAN) as an assistance information where RAN makes use of the provided assistance information to enhance / optimize the existing or any new procedures i.e., power / energy saving, capacity enhancements etc. for example within 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) and NR-based networks. Description of the Related Art References: [1] 3GPP TS 22.261 “Service requirements for the 5G system”. [2] 3GPP TR 38.838 “Study on XR Evaluations for NR (Rel-17)”. [3] 3GPP TR 38.835 “Study on XR enhancements for NR (Rel-18)”. [4] 3GPP TR 23.700-60 “Study on XR (Extended Reality) and media services (Rel-18)”. [5] SP-220809 “New WID: UPF enhancement for Exposure and SBA”. [6] 3GPP TS 23.501 “System Architecture for the 5G System; Stage 2”. [7] 3GPP TS 23.502 “Procedures for the 5G System (5GS); Stage 2”. [8] 3GPP TS 23.503 “Policy and charging control framework for the 5G System (5GS); Stage 2”. Augmented, virtual and mixed reality (ARA / R / MR) services or the umbrella term for these services known as extended reality (XR) services are expected to be attractive use cases that will impose a set of challenges for 5G and beyond networks to provide stringent service requirements [1], Nevertheless, the XR services has a set of traffic characteristics such as traffic periodicity, data burst arrival time, jitter, etc. that can be useful to improve network efficiency by means of resource utilization and power consumption. 5G NR evaluations forXR and media (XRM) traffic characteristics have been studied in 3GPP Release 17 as RAN1 study item [2], and further enhancements on RAN (RAN2) [3] and SA (SA2) [4] are currently being studied in 3GPP Release 18. The noted studies have one objective that is to study XR-specific power saving / management techniques to accommodate XRM service / traffic characteristics including periodicity / pattern, jitter, latency, reliability, etc. In [3], the following information provided by the CN is noted as useful for RAN: In order to handle PDUs efficiently in both UL and DL, the following information would be useful: Semi-static information provided by the CN: The PDU-Set Delay Budget (PSDB); - The PDU-Set Error Rate (PSER); Traffic parameters (e.g. periodicity): Jitter information (e.g. range). In [4], the key issue focuses on enhancements to power savings forXR services is concluded as: The following information, to be provided to the NG-RAN at PDU Session Establishment / Modification via an NGAP Message, is taken as baseline for normative work: Periodicity for UL and DL traffic of the QoS Flow. In addition to integer periodicity values, noninteger values associated to, e.g. 15 FPS, 30 FPS, 45FPS, 60 FPS, 72 FPS, 90FPS, 120FPS, shall be supported. Such information shall be exchanged by re-using / extending the TSCAI / TSCAC definitions in clause 5.27.2.1 of TS 23.501 [21. NOTE 1: The above information can be provided to the 5GC by the AF via an NEF API. The 5GC can further derive, or be configured, with such information. Traffic jitter information (e.g. jitter range) associated with each periodicity. The SMF reguests the UPF to derive jitter (i.e. N6 jitter) fora given periodicity. 5GC derives jitter information accordingly and forwards it to the RAN along with periodicity. NOTE 2: How the UPF derives the jitter is left for implementation. How the SMF obtains and provides the jitter information will be defined in the normative phase. 15 In [4], the following terms specific to XR and media traffic are also defined: PDU Set: A PDU Set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g. a frame or video slice for XRM Services, as used in TR 26,926

[27] ). In some implementations all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts all or of the information unit, when some PDUs are missing. Data Burst: A set of multiple PDUs generated and sent by the application in a short period of time. The following PDU Set QoS parameters are defined to support PDU Set handling: NOTE 1: The definitions of PSER and PSDB can be revisited during normative phase. PDU Set Error Rate: The PDU Set Error Rate (PSER) defines an upper bound for the rate of PDU Sets that have been processed by the sender of a link layer protocol (e.g. RLC in RAN of a 3GPP access) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in RAN of a 3GPP access). Thus, the PSER defines an upper bound for a rate of non-congestion related packet losses. The purpose of the PSER is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in RAN of a 3GPP access). For every 5QI the value of the PSER is the same in UL and DL. If any PDU within the PDU Set is not successfully transmitted, the PDU Set is treated as error. NOTE 2: In this release, a PDU set is considered as successfully delivered when all PDUs of a PDU Set are delivered successfully. PDU Set Delay Budget: The PSDB defines an upper bound for the delay that a PDU Set may experience for the transfer between the UE and the N6 termination point at the UPF. i.e. time between reception of the first PDU and the successful delivery of the last arrived PDU of a PDU Set. PSDB applies to the DL PDU Set received by the UPF over the N6 interface, and to the UL PDU Set sent by the UE. For a certain 5QI the value of the PSDB is the same in UL and DL. In addition to XR-related studies, in User Plane Function (UPF) enhancements for exposure and SBA work item description [5], the following note is captured to allow other studies, especially XR and Media, to define the parameters to be exposed by UPF to other Network Functions (NFs) such as Network Data Analytics Function (NWDAF), Application Function / Network Exposure Function (AF / NEF) and Time-Sensitive Networking (TSN) AF per conclusion in TR 23.700-62. 4 Objective The objective of this work item is to define the normative specifications of the solutions to enhance 5GS as per conclusions reached within TR 23.700-62 for the following aspects: Enhancement in 5GC system to support UPF event exposure service registration and discovery in NRF per conclusion in clause 8.1. Enhancement in 5GC system to support UPF expose information to other NFs i.e. NWDAF, AF / NEF and TSN AF per conclusion in clause 8.2. NOTE : UPEAS defines the framework for exposure from UPF: other WIDs (e.g. XRM. EC) may define the parameters to be exposed. Packet Delay Measurements In current specification TS 23.501 [6], packet delay budget (PDB) is defined as an upper bound for the time that a packet may be delayed between the UE and the N6 termination point at the UPF. The PDB applies to the DL packet received by the UPF over the N6 interface, and to the UL packet sent by the UE. With the introduction of URLLC (Ultra Reliable Low Latency Communication) services, the PDB is identified separately for the Access network as 5G-AN PDB (5G Access Network Packet Delay Budget) and CN PDB (Core Network Packet Delay Budget). Therefore, the packet delay between UE and UPF is now a combination of the RAN part of UL / DL packet delay and UL / DL packet delay between NG-RAN and UPF. Figure 1 illustrates the reference time points that are used to measure UL and DL packet delays as explained in 23.501, Clause 5.33.3. According to the figure, the DL packet delay between UPF and RAN can be obtained with T2-T1 and the UL packet delay between RAN and UPF can be obtained with T4-T3. The delay between the RAN and UE (and vice versa) is obtained by RAN-based packet delay measurement mechanism on Uu interface where details are captured in TS 38.314, and RAN provides the measured delay information to UPF along with the time stamps of T2 and T3. Packet delay measurements can be obtained as one way such as UL / DL packet delay or round-trip transmission (RTT) delay where RTT between RAN and UPF, RTT1, can be obtained with (T4-T1) - (T3-T2); RTT between RAN and UE, RTT2, can be obtained based on RAN-specific delay measurement mechanisms; and; - RTT between UPF and UE, RTT3, can be obtained as RTT3 = RTT1 + RTT2. In addition, packet delay measurements can be performed by using GTP-U Echo Request / Response as defined in TS 28.552, in the corresponding user plane transport path(s), independent of the corresponding PDU session and the 5QI for a given QoS flow for a specific URLLC service. Moreover, TS 28.552 also notes that in Operations, Administration and Maintenance (OAM), distribution of packet delays between UPF and RAN as well as UPF and UE, which can be a representative of jitter, are derived. Time Sensitive Communications (TSC) Current specification TS 23.501 [6] describes 5G system features that enable time sensitive communications (TSC) and time synchronization. In order for 5G system to support TSC, the UE shall request an always-on PDU session. TSC QoS Flows use a Delay-critical Guaranteed Bit Rate (GBR) resource type and TSC Assistance Information (TSCAI) that describes TSC QoS flow traffic characteristics which may be provided optionally for use by the gNB to allow more efficiently schedule radio resources for periodic traffic. In clause 5.27.3 in TS 23.501 [6], it is noted that: TSC QoS Flows may use standardized 5Qls, pre-configured 5Qls or dynamically assigned 5QI values (which requires signalling of QoS characteristics as part of the QoS profile) as specified in clause 5.7.2. For each instance of Periodicity, within each Period (defined by periodicity value). TSC QoS Flows are required to transmit only one burst of maximum size MDBV within the 5G-AN PDB. Known QoS Flow traffic characteristics provided in the TSCAI may be used to optimize scheduling in the 5GS. In the current specification TS 23.501, the AF / NEF can provide the traffic characteristics information to the Time Sensitive Communication and Time Synchronization Function (TSCTSF), see below for more details. The TSCTSF constructs a TSC Assistance Container (including flow direction, periodicity, Burst Arrival Time and Survival Time) for an application which is then provided to the Session Management Function (SMF) via the Policy Control Function (PCF). AF session with Required QoS In current specifications TS 23.501 [6], TS 23.502 [7], TS 23.503 [8], setting up an AF session with required QoS procedure is defined so that an AF can provide individual parameters for QoS as well as Alternative QoS / Service requirements. Based on information provided in TS 23.502 [7], the AF sends a request to reserve resources for an AF session using Nnef_AFsessionWithQoS_Create request message to the NEF where the request message includes UE address, - AF Identifier, Flow description(s) or External Application Identifier, QoS reference, - QoS parameters, - Alternative Service Requirements, - DNN, - S-NSSAI. Optionally, a period of time or a traffic volume for the requested QoS can be included in the AF request. The AF may, instead of a QoS Reference, provide the following individual QoS parameters: Requested 5GS Delay (optional), - Requested Priority (optional), - Requested Guaranteed Bitrate, - Requested Maximum Bitrate. Regardless, whether the AF request is formulated using a QoS Reference or Individual QoS parameters, the AF may also provide the following optional QoS parameters: Flow Direction, - Burst Size, - Burst Arrival Time at UE (uplink) or UPF (downlink), Periodicity, Time domain, Survival Time. When optional Alternative Service Requirements are provided by the AF request that is formulated with the help of Individual QoS parameters, Requested Alternative QoS Parameter Set(s) may be provided instead of a QoS Reference. The Requested Alternative QoS Parameter Set(s) are provided in a prioritized order where each set is comprised of Requested 5GS Delay and Requested Guaranteed Flow Bitrate. Based on TS 23.503 [8] Clause 6.1.3.22: When the PCF authorizes the service information from the AF, it derives the QoS parameters of the PCC rule based on the service information and the individual QoS parameters received from the AF and TSCTSF. The PCF should select a standardized, pre-configured or existing dynamically assigned 5QI that matches the individual QoS parameters. If no 5QI exists that matches the individual QoS parameters, the PCF generates a new dynamically assigned 5QI based on the individual QoS parameters. Core Network assistance information for RAN optimization Based on TS 23.501 [6], Core Network (CN) assistance information for RAN aids the RAN to optimize the UE state transition steering and the RAN paging strategy formulation in RRC Inactive state. The Core Network assistance information includes: Core Network assisted RAN parameters tuning, which assist RAN optimize the UE RRC state transition and Connected Mode (CM) state transition decision; Core Network assisted RAN paging information, which assist RAN to formulate an optimized paging strategy when RAN paging is triggered. Core Network assisted RAN parameters tuning may be derived by the Access and Mobility Management Function (AMF) per UE in the AMF based on collection of UE behaviour statistics, Expected UE Behaviour and / or other available information about the UE. If the AMF maintains Expected UE Behaviour parameters, Network Configuration parameters as described in clause 4.15.6.3 or 4.15.6.3a in TS 23.502 [7] or SMF derived CN assisted RAN parameters tuning, the AMF may use this information for selecting the CN assisted RAN parameter values. The SMF uses the SMF-Associated parameters (e.g. Expected UE Behaviour parameters or Network Configuration parameters of the UE) to derive CN assisted RAN parameters tuning. The SMF sends the SMF derived CN assisted RAN parameters tuning to the AMF during the PDU Session establishment procedure and if the SMF-Associated parameters change the PDU Session modification procedure is applied. The AMF uses the SMF derived CN assisted RAN parameters tuning to determine a PDU Session level "Expected UE activity behaviour" parameters set, which may be associated with a PDU Session ID. In TS 23.502 [7], it is noted that: The Expected UE Behaviour parameters or the Network Configuration parameters can be provisioned by external party via the NEF to the AMF or SMF. Regarding the CN assisted RAN paging information, it may be derived by the AMF per UE and / or per PDU Session based on collection of UE behaviour statistics, Expected UE Behaviour and / or other available information about the UE (such as subscribed DNN, SUPI ranges, Multimedia priority service), and / or information received from other network functions when downlink signalling is triggered. The AMF can provide this assistance information that is named as “RRC Inactive Assistance Information” to the NG-RAN in order to assist the NG-RAN's decision whether the UE can be sent to RRC Inactive state. The "RRC Inactive Assistance Information" includes UE specific Discontinuous Reception (DRX) values; UE specific extended idle mode DRX values (cycle length and Paging Time Window length); etc. as detailed in TS 23.501 [6], The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present invention. SUMMARY It is an aim of certain examples of the present disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein. The present invention is defined in the independent claims. Advantageous features are defined in the dependent claims. Embodiments or examples disclosed in the description and / or figures falling outside the scope of the claims are to be understood as examples useful for understanding the present invention. Other aspects, advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates an example of reference time points that are used to measure UL and DL packet delays; Figure 2 illustrates an example procedure for UPF and / or NWDAF to derive / obtain XR and media traffic characteristics; and Figure 3 is a block diagram of an exemplary network entity that may be used in certain examples of the present disclosure. DETAILED DESCRIPTION The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the present invention, as defined by the claims. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made. The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings. Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure. The terms and words used herein are not limited to the bibliographical or standard meanings, but, are merely used to enable a clear and consistent understanding of the examples disclosed herein. Throughout the description and claims, the words “comprise”, “contain” and “include”, and variations thereof, for example “comprising", “containing” and “including”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, functions, characteristics, and the like. Throughout the description and claims, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects. Throughout the description and claims, language in the general form of “X for Y” (where Y is some action, process, function, activity or step and X is some means for carrying out that action, process, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y. Features, elements, components, integers, steps, processes, functions, characteristics, and the like, described in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim disclosed herein unless incompatible therewith. The following examples are applicable to, and use terminology associated with, 3GPP 5G. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 5G, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 5G, 5G-advanced, 6G, or any other relevant standard. For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network. For example, the functionality of an IAB node in the examples below may be applied to any other suitable type of entity performing functions of a network node. The skilled person will appreciate that the present invention is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements, entities and / or messages may be added to the examples disclosed herein. • One or more non-essential elements, entities and / or messages may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed may be modified, if possible, in alternative examples. • The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein. Certain examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Such an apparatus / device / network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / funotion of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g. a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor. It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, claim, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program. While the invention has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention, as defined by the appended claims. Certain examples of the present disclosure provide one or more techniques as disclosed in the appended annex to the description. The skilled person will appreciate that any of these techniques may be applied in combination with any of the techniques described above and illustrated in the Figures. Connected mode Discontinuous Reception (CDRX) procedure may be used to send packets to UE in a pre-configured time duration (“ON” time) and let UE to get into sleep mode (“OFF” time) for a certain period of time to reduce power consumption at the UE. Otherwise, UE has to be in listening mode even if there is no active transmission to the UE. With the introduction of XRM services, the traffic pattern / periodicity and the jitter information of the XRM services would have an impact on RAN power saving configurations (e.g., CDRX, PDCCH monitoring, etc.). Therefore, the XRM service jitter and periodicity information could help RAN to optimize the existing configurations to improve power saving. Accordingly, it is an aim of certain embodiments of the present disclosure to provide methods, apparatus and systems for addressing the above-identified and related issues, for example by enabling a way to help RAN to optimize UE power saving / CDRX procedure by providing jitter and periodicity information to RAN which is currently missing in the related specifications. It is an aim of certain embodiments of the present disclosure to provide methods, apparatus and systems to derive and / or incorporate jitter / periodicity information specific to XRM services. For example, the distribution of the packet delay or in other words, jitter information, is not derived in the current procedures. The distribution of the packet delay measurements between RAN and UPF as well as UPF and UE can be derived in OAM. However, using OAM data to optimize RAN procedure will not be feasible as the OAM data would be on high level such as on application- or service-level and would be based on long term measurements. Optimizing a RAN procedure requires a finer granularity on the collected / derived information. Given that the RAN can have instantaneous packet delay measurements and may derive jitter information on Uu interface accordingly, this information would not represent the packet delay and jitter on N3 interface which would affect the traffic periodicity and jitter for RAN to take into account to optimize power saving configurations. Moreover, the existing QoS monitoring to assist URLLC services does not consider delay distribution / jitter which is needed for XRM services (HDRLL services). In addition to these, the existing periodicity information for TSCAI refers to the time period between start of two data bursts where within each periodicity, there can be only one burst of maximum volume can be transmitted within the given 5G-AN PDB. The description of the periodicity in TSC may not fully match with the periodicity as part of XRM traffic characteristics as XRM has defined PDUs within PDU Set. Hence, the periodicity can be interpreted as between PDU Sets and does not match with packet bursts-based periodicity defined for TSC. Also, as noted above, in order to utilize TSC QoS Flows, the resource type of 5QI should be chosen as delay-critical GBR. However, based on TR 26.928 [9], some XR applications / use cases may have differentiated latency requirements in the range of 10 ms to several 100 ms with a bitrate guarantee. Existing 5QI values may address these application / use cases but the ones that address the requirements are noted as non-GBR bearers, i.e., 5QI=80 with 10ms. Therefore, on the one hand, establishing a PDU session with delay-critical GBR (if TSCAI is used to provide QoS characteristics) may not be considered as an appropriate / optimal solution as it may invoke extra monitoring / reporting at the UE as well as RAN / CN for these applications / use cases. On the other hand, having a non-GBR bearer (like 5QI=80) would not enable network to control the service requirements as the traffic would be transmitted as best effort and power saving / capacity gain with respect to XRM traffic characteristics may not be achieved. Accordingly, it is an aim of certain embodiments of the present disclosure to provide methods, apparatus and systems for addressing the above-identified and related issues, for example by providing mechanisms to collect and / or derive jitter and periodicity information at 5G CN (i.e., UPF / SMF / PCF); and procedures to provide jitter and periodicity information derived at 5G CN to RAN. Certain embodiments specify XR and media traffic specific information, namely, jitter and periodicity information by providing jitter and periodicity measurement collection procedure and procedures on how to provide the information to RAN as an assistance information where RAN makes use of the provided assistance information to enhance / optimize the existing or any new procedures i.e., power / energy saving, capacity enhancements etc. According to certain examples, UPF performs packet delay measurements between NG-RAN and UPF (N3), UPF and UE (N3 and Uu interface) and UPF and AF (N6) and gathers 5G AN PDB from RAN. UPF obtains distribution of packet delay measurements between NG-RAN and UPF (N3), UPF and UE (N3 and Uu interface) and UPF and AF (N6) for a given time window / bin size. The given time window / bin size can be different than the existing “Averaging window” as the existing “Averaging window” is defined to obtain average bit rate, not delay / latency. Therefore, considering the same value for latency / jitter calculation may not represent the granularity needed to obtain jitter range / latency distribution specific to XRM traffic characteristics. The distribution calculation time window / bin size can be configured by AF / PCF / SMF. The given time window can be captured based on XR and / or media traffic characteristics, e.g., periodicity and / or data burst / burst arrival time (within PDUs in a PDU set and / or PDU sets) or N times (where N is an integer) the periodicity / data burst / burst arrival time (within PDUs in a PDU set and / or PDU sets) or it can be any value decided by AF / PCF / SMF. For example, the given distribution calculation time window for jitter calculation can be equal to N=4 times the traffic periodicity e.g., the periodicity defined for XRM traffic. In case AF provides this information, it can be provided by utilizing the existing Nnef_AFsessionWithQoS_Create and / or Nnef_AFsessionWithQoS_Update request. Periodicity information can also be provided by AF to 5GC with the existing mechanisms (Nnef_AFsessionWithQoS_Create and / or Nnef_AFsessionWithQoS_Update) and / or it can be obtained by UPF with proper packet handling at UPF N6 interface. UPF can make use of AF provided periodicity information and arrival time range of incoming packets at N6 ingress point to obtain jitter / packet delay measurements on N6 interface (between AF / Application Server / DN and UPF). The packet delay distribution outcome can be considered as jitter information and it can be captured as, for example, mean value, minimum value, maximum value and / or variance of the packet delays overthe given time window. However, the jitter information is not limited to these examples and may be any information indicative of the jitter or packet delay distribution. The periodicity information may be, for example, the PDU set periodicity or the periodicity among PDUs in a PDU set. However, the periodicity information is not limited to these examples and may be any information indicative of the periodicity. UPF may provide the packet delay distribution / jitter information and / or periodicity information directly to 5GC NFs (i.e., SMF and / or NWDAF and / or AF / NEF including TSN AF). SMF / PCF may use the XR-specific traffic characteristics (i.e., packet delay distribution / jitter, PDU set periodicity, periodicity among PDUs in a PDU set, etc.) which then can be provided to RAN as an assistance information to optimize power saving procedures. AF / NEF may also use the analytics and statistics, i.e., by utilizing the existing Nnef_AFsessionWithQoS_Create and / or Nnef_AFsessionWithQoS_L / pdate request. In an example where NWDAF provides the analytics to SMF, SMF may provide jitter range and periodicity information that reflects the requested / ongoing XR and media traffic characteristics to the RAN, and RAN (re)configures CDRX parameters such as long / short DRX cycle, “ON” duration, and DRX inactivity timer. SMF may also use the XR-specific information parameters to decide whether keep or remove the redundant transmission on N3 / N9 interface. When SMF getsXR and media traffic characteristics information that may include packet delay distribution / jitter, PDU set periodicity, periodicity among PDUs in a PDU set, etc., SMF sends the RAN assistance information as part of: o TSC (Time Sensitive Communication) Assistance Information; or o SMF derived CN assisted RAN parameters tuning, per established PDU Session; or o AMF provided RRC Inactive Assistance Information. Deriving jitter information In certain embodiments of the present disclosure, network entities may obtain a packet delay measurement, obtain a jitter calculation parameter, and obtain jitter information based on the packet delay measurement and the jitter calculation parameter. The jitter information may be obtained at a first network entity, for example a core network entity or RAN entity (e.g. RAN node / or gNB). The core network entity may be a 5GC entity, for example, a UPF, SMF, PCF, or any other 5GC entity. In certain embodiments of the present disclosure, after obtaining the jitter information, the first network entity may transmit the jitter information to a second network entity. The second network entity may be a core network entity, (for example an SMF) or may be a RAN entity (e.g. RAN node orgNB). In certain embodiments, if the second network entity is a core network entity, the second network entity may then transmit the received jitter information to the RAN. In certain embodiments of the present disclosure, the jitter information may be transmitted to the RAN as part of RAN assistance information. Deriving jitter information at UPF UPF obtains packet delay measurements on N3 / N9 and NG-RAN by using the existing mechanism (for example, see TS 23.501 Clause 5.33.3). For UPF to obtain the packet delay distribution / jitter, according to certain embodiments of the present disclosure, UPF obtains a jitter calculation parameter either from AF / SMF / PCF ordecides the jitter calculation parameter on its own where it reports the considered jitter calculation parameter along with the measurement report to 5GC NF(s) such as SMF, NWDAF. The jitter calculation parameter is used to calculate the packet delay distribution / jitter information and may be, for example, an averaging window, a distribution calculation window, a bin size, or a measurement period. For UPF to perform packet delay measurements on N6 interface, according to certain embodiments of the present disclosure, AF / Application server may include timestamp(s) or time information to XR and media traffic packets, i.e., packet headers can be extended to include time information. When AF / application server sends out packets i.e., monitoring request packet, to UP, AF / application server records the local time TX where X represents an integer indicator that can be chosen different from the existing ones such as X=6, T6 (as shown in Figure 1). The AF / application server also sends the TX information to UPF. Then, UPF records the local time T(X+1) when receiving the packet from the AF / application server and reads TX information. UPF also obtains AF / application server to UPF delay / N6 interface DL delay by (T(X+1) - TX). When UPF send out packets i.e., monitoring response packet, to the AF / application server, UPF records the local time T(X+2) and sends it along with the obtained N6 DL interface delay. When the AF / application server receives the packet, i.e., monitoring response packet, from UPF, it records the local time T(X+3) and reads information on N6 DL interface delay as well as T(X+2) to obtain N6 UL interface delay. The described operation above is valid when AF and UPF are time synchronized. In case the AF and UPF are not time synchronized, AF obtains the delay for X=6 as ( (T9-T6) - (T8-T7) ) / 2 or (T7-T6+T9-T8) / 2. With the same procedure described above, the UPF / AF may obtain the packet delay distribution / jitter by using the measured packet delay on N6 interface and provides the packet delay distribution / jitter as a novel part of N6 interface information. The same jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) used for obtaining packet delay distribution / jitter on N3 interface or UPF to UE can be used to obtain the packet delay distribution / jitter on N6 interface. There can be cases where the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) is different for different traffic directions. For example, the jitter calculation parameter may be different for UL and DL directions. In that case, UPF provides the considered jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement) period for both UL and DL separately. In another embodiment, the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) for both UL and DL can be pre-configured or deterministic. In certain embodiments of the present disclosure, the QoS Monitoring policy may contain the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) along with the QoS parameters to be monitored which include packet delay distribution / jitter as one of the parameters, event report triggers to trigger observed packet delay distribution / jitter along with the other QoS parameters, the threshold of QoS parameters including packet delay distribution / jitter as a measurement value or a percentage of change / change rate and the relevant actions when threshold (as a measurement value or a percentage of change / change rate) is exceeded are also included in the QoS Monitoring policy. The QoS Monitoring Policy can also be pre-configured at SMF by the operator, hence, the operator may decide the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period). The jitter calculation parameter can be, for example, the same bin size used in QAM for the existing packet delay distribution information. The jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) may be captured based on XR and / or media traffic characteristics, e.g., periodicity and / or data burst / burst arrival time (e.g. within PDUs in a PDU set and / or PDU sets) or N times (where N is an integer) the periodicity / data burst / burst arrival time (e.g. within PDUs in a PDU set and / or PDU sets) or it can be any value decided by AF / PCF / SMF. For example, the given distribution calculation time window for packet delay distribution / jitter calculation can be equal to N=4 times the traffic periodicity e.g., the periodicity defined for XRM traffic. When receiving the QoS Monitoring Policy from the PCF, the SMF maps the QoS Monitoring Policy including packet delay distribution / jitter monitoring in the Usage Reporting Rules (URRs) to the UPF. In certain embodiments of the present disclosure, the URR includes QoS parameters including packet delay distribution / jitter to be monitored, reporting threshold as a measurement value or a percentage of change / change rate, relevant action, and event report for specific QoS flows. When the event report(s) is triggered, e.g. when the UL / DL packet delay distribution (e.g. mean / variance) / jitter is higher than the threshold as a measurement value, or the UL / DL packet delay distribution (e.g. mean / variance) / jitter is changed higher than the threshold as a percentage of change / change rate, the UPF can report the events via N4 interface. The UPF sends N4 Report to the SMF carrying the QoS Monitoring Event Report: Timestamp of event, Name of event i.e., value higher than the threshold as threshold being a measurement value or percentage of change / change rate, measured value of QoS parameter i.e., packet delay distribution as mean and variance / jitter, PDU Session ID, QFI. In case the UPF decides the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period), the UPF includes the considered jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) to N4 Report to the SMF. In addition to N4 report to the SMF, UPF may report the observed / obtained packet delay distribution / jitterto NWDAF and / orto AF along with the considered / configured jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) information. After receiving the QoS monitoring events report from UPF, the SMF may forward the report to e.g. PCF. In certain embodiments of the present disclosure, the SMF may derive the RAN assistance information related to packet delay distribution / jitter or may forward the report to AMF to derive the RAN assistance information related to packet delay distribution / jitter i.e., as part of expected UE behaviour, as described in detail below. Deriving jitter information at RAN RAN obtains UL / DL packet delay measurements on Uu interface by using the existing mechanisms (e.g. as defined in TS 38.314). In certain embodiments of present disclosure, for RAN to obtain the packet delay distribution / jitter information, RAN may get a jitter calculation parameter (e.g. an averaging window / distribution calculation window / bin size / measurement period) from AMF / SMF. The SMF may notify the RAN (and UE) to enable the QoS Monitoring including packet delay distribution / jitter for the QoS Flow via the Namf Communication N1 N2MessageTransfer message and PDU Session Establishment / Modification Command message. In certain embodiments of the present disclosure, RAN node / gNB may decide the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) on its own where it reports the considered jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) along with the measurement report. The jitter calculation parameter may be calculated in the same way as set out above for the UPF, for example based on XR and / or media traffic characteristics, e.g., periodicity and / or data burst / burst arrival time (e.g. within PDUs in a PDU set and / or PDU sets) or N times (where N is an integer) the periodicity / data burst / burst arrival time (e.g. within PDUs in a PDU set and / or PDU sets). There can be cases where the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) is different for UL and DL directions. In that case, RAN provides the considered jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) for both UL and DL separately. According to certain embodiments of the present disclosure, RAN provides the packet delay distribution (e.g. mean, variance) / jitter information along with the measured delay information, i.e. the time stamps of T2 and T3 depicted in Figure 1, to UPF. Deriving jitter information at other 5GC NFs (e.g., SMF, PCF) Optionally to UPF and / or RAN-based calculation, the packet delay distribution / jitter information may be derived at one of the 5GC NFs such as SMF, PCF, etc. According to certain embodiments of the present disclosure, in case of SMF-based derivation, SMF utilizes the measurement reports from UPF as part of N4 reports, and derives packet delay distribution / jitter information according to the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) that may be provided by PCF / TSCTSF / AF or decided by the SMF itself. The jitter calculation parameter may be calculated in the same way as set out above for the UPF and RAN, for example based on XR and / or media traffic characteristics, e.g., periodicity and / or data burst / burst arrival time (e.g. within PDUs in a PDU set and / or PDU sets) or N times (where N is an integer) the periodicity / data burst / burst arrival time (e.g. within PDUs in a PDU set and / or PDU sets). According to certain embodiments of the present disclosure, in case of PCF-based derivation, PCF may subscribe to UPF reports on QoS Monitoring and derives packet delay distribution / jitter information based on the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) that may be provided by TSCTSF / AF or decided by the PCF itself. The jitter calculation parameter may be calculated in the same way as set out above for the UPF and RAN, for example based on XR and / or media traffic characteristics, e.g., periodicity and / or data burst / burst arrival time (e.g. within PDUs in a PDU set and / or PDU sets) or N times (where N is an integer) the periodicity / data burst / burst arrival time (e.g. within PDUs in a PDU set and / or PDU sets). Providing XR and media traffic characteristics to NG-RAN When SMF gets XR and media traffic related measurements / information from UPF as part of N4 report including UPF-derived packet delay distribution / jitter information (that may include maximum, minimum, average and variance of observed packet delay) or from any other 5GC NF including NWDAF (the information from NWDAF may include estimated jitter range, estimated traffic periodicity, etc.), SMF sends the jitter information as part of the RAN assistance information to NG-RAN which can be in the form of: o TSC (Time Sensitive Communication) Assistance Information; or o SMF derived CN assisted RAN parameters tuning, per established PDU Session; or o AMF provided RRC Inactive Assistance Information. For the case of TSCAI: In certain embodiments of the present disclosure, the TSCTSF constructs TSC Assistance Container (TSCAC) based on information provided (directly or via NEF) by the AF which may include XR-specific parameters e.g., packet delay distribution / jitter, PDU set periodicity, 5 periodicity among PDUs in a PDU set, etc. Then, the SMF determines the TSCAI for the QoS Flow based on the TSCAC of the PCC rule bound to the QoS Flow. Hence, the existing TSCAI (TS 23.501 [6], Table 5.27.2-1: TSC Assistance Information (TSCAI)) and TSCAC (TS 23.501 [6], Table 5.27.2-2: TSC Assistance Container (TSCAC)) information parameters can be updated partly with the following assistance information elements / parameters underlined 10 below in Tables 1 and 2. For example, the assistance information may include PDU Set Periodicity, which is periodicity of PDU sets / PDUs in a PDU set (mean and variance) for UEs communicating with the application, i.e., XR application; and Packet Delay distribution / Jitter, which is the packet delay distribution / jitter among PDU sets. Table 1 (based on TS 23.501 [6], Table 5.27.2-1, TSC Assistance Information (TSCAI)): Assistance Information Description Flow Direction The direction of the TSC flow (uplink or downlink). Periodicity It refers to the time period between start of two data bursts. Burst Arrival Time (optional) The latest possible time when the first packet of the data burst arrives at either the ingress of the RAN (downlink flow direction) or the egress of the UE (uplink flow direction). Survival Time (optional) Survival Time, as defined in TS 22.261, refers to the time period an application can survive without any data burst. PDU Set Periodicity (optional) Periodicity of PDU sets / PDUs in a PDU set (mean and variance) for UEs communicating with the application, i.e., XR application. Packet Delay distribution / Jitter (optional) The packet delay distribution / jitter among PDU sets. Table 2 (based on TS 23.501 [6], Table 5.27.2-2: TSC Assistance Container (TSCAC)): Information Description Flow Direction The direction of the TSC flow (uplink or downlink). Periodicity It refers to the time period between start of two data bursts. Burst Arrival Time (optional) The time when the first packet of the data burst arrives at the ingress port of5GS for a given flow direction (DS-TT for uplink, NW-TT for downlink). Survival Time (optional) It refers to the time period an application can survive without any data burst, as defined in TS 22.261. Time Domain (optional) The (g)PTP domain of the TSC flow. PDU Set Periodicity (optional) Periodicity of PDU sets / PDUs in a PDU set (mean and variance) for UEs communicating with the application, i.e., XR application. Packet Delay distribution / Jitter (optional) The packet delay distribution / jitter among PDU sets. As the SMF corrects the Periodicity in the TSCAC using the existing mechanism (i.e., using the cumulative rateRatio if the cumulative rateRatio was previously received from the UPF), the SMF may also correct PDU Set Periodicity and sets the TSCAI PDU Set Periodicity as the corrected value. Otherwise, the SMF sets the received PDU Set Periodicity in the TSCAI without any correction. In a similar manner, if Survival Time may be provided in terms of maximum number of messages or maximum number of PDU sets or maximum number of PDUs in a PDU set, and the SMF converts the maximum number of PDU sets or maximum number of PDUs in a PDU set into time units by multiplying its value by the TSCAI PDU Set Periodicity, and sets the TSCAI Survival Time to the calculated value specific to XRM traffic. In order to prevent frequent updates from the UPF, the UPF sends the offset or the cumulative rateRatio only when the difference between the current measurement and the previously reported measurement is larger than a threshold as currently described in clause 4.4.3.4 of TS 23.502 [7] and / or larger than a percentage of change / change rate. In certain embodiments of the present disclosure, SMF may use the XR-specific information parameters to keep or remove the redundant transmission on N3 / N9 interface. For the case of SMF derived CN assisted RAN parameters tuning: The XR-specific parameters e.g., packet delay distribution / jitter, PDU set periodicity, periodicity among PDUs in a PDU set, etc. may be used to characterise the foreseen behaviour of a UE or a group of UEs. In certain embodiments of the present disclosure, the SMF uses the SMF-associated parameters such as Expected UE behaviour or Network configuration parameters which may include XR-specific parameters to derive SMF derived CN assisted RAN parameters tuning. The SMF sends the SMF derived CN assisted RAN parameters tuning that include XR-specific parameters e.g., packet delay distribution / jitter, PDU set periodicity, periodicity among PDUs in a PDU set, etc. to the AMF during the PDU Session establishment / modification procedure. The AMF may use the SMF derived CN assisted RAN parameters tuning with XR-specific parameters to determine a PDU Session level "Expected UE activity behaviour" parameters set, which may be associated with a PDU Session ID and / or PDU Set ID and / or application ID. The CN assisted RAN parameters tuning provides the RAN with a way to understand the UE behaviour for the existing aspects such as Expected UE activity behaviour, Expected HO behaviour, Expected UE mobility, Expected UE moving trajectory, UE Differentiation Information as well as for a new aspect proposed in this disclosure as Expected UE traffic characteristics including packet delay distribution / jitter, PDU set periodicity, periodicity among PDUs in a PDU set, which may also be incorporated to the Expected UE Behaviour parameter list (see Table 4.15.6.3a-1: Description of Network Configuration Parameters in TS 23.502 [7]) as underlined below in Table 3. For example, a new expected UE behaviour parameter may 5 be included, such as application transmission periodicity, which is the periodicity of application data transmission, for example periodicity of PDU sets / PDUs in a PDU set of an XR application. Furthermore, an existing parameter such as the traffic profile may be modified to include PDU set transmission. Table 3 (based on Table 4.15.6.3a-1: Description of Network Configuration Parameters in TS 10 23.502 [7]) Expected DE Behaviour parameter Description Expected UE Moving Trajectory Identifies the UE's expected geographical movement Example: A planned path of movement Stationary Indication Identifies whether the UE is stationary or mobile [optional] Communication Duration Time Indicates for how long the UE will normally stay in CM-Connected for data transmission. Example: 5 minutes. [optional] Periodic Time Interval Time of periodic communication Example: every hour. [optional] Application Transmission Periodicity Periodicity of application data transmission Example: Periodicity of PDU sets / PDUs in a PDU set of an XR application [optional] Scheduled Communication Time Time and day of the week when the UE is available for communication. Example: Time: 13:00-20:00, Day: Monday. [optional] Battery Indication Identifies power consumption criticality for the UE: if the UE is battery powered with not rechargeable / not replaceable battery, battery powered with rechargeable / replaceable battery, or not battery powered. [optional] Traffic Profile Identifies the type of data transmission: single packet transmission (UL or DL), dual packet transmission (UL with subsequent DL or DL with subsequent UL), multiple packets transmission including PDU set transmission [optional] Scheduled Communication Type Indicates that the Scheduled Communication Type is Downlink only or Uplink only or Bi-directional [To be used together with Scheduled Communication Time] Example: <Scheduled Communication Time>, DL only. [optional] Expected Time and Day of Week in Trajectory Identifies the time and day of week when the UE is expected to be at each location included in the Expected UE Moving Trajectory. [optional] In certain embodiments of the present disclosure, in addition to the Expected UE Behaviour parameters, Network Configuration Parameters (for example, see Table 4.15.6.3a-1: Description of Network Configuration Parameters in TS 23.502 [7]) can also be extended to 15 include XR-specific traffic characteristics / parameters e.g., packet delay distribution / jitter, PDU set periodicity, periodicity among PDUs in a PDU set, etc. as underlined below in Table 4. For example, a new network configuration parameter may be included such as maximum latency variance / jitter, which identifies a maximum jitter acceptable for downlink data transfers, for example in the order of 1 minute to multiple hours. Table 4 (based on Table 4.15.6.3a-1: Description of Network Configuration Parameters in TS 23.502 [7]): Network Configuration parameter Description Maximum Response Time Identifies the time for which the UE stays reachable to allow the AF to reliably deliver the required downlink data. [optional] Maximum Latency Identifies maximum delay acceptable for downlink data transfers. Example: in order of 1 minute to multiple hours. [optional] Maximum_______Latency Variance / Jitter Identifies maximum jitter acceptable for downlink data transfers. Example: in order of 10 ms to 100 ms. [optional] Suggested Number of Downlink Packets Identifies the number of packets that the core network is suggested to buffer if the UE is not reachable. Example: 5 packets. [optional] The proposed parameters above can be stored in UDM per UE level and / or per PDU session level and / or per PDU Set level and / or per application level. SMF / AMF retrieves SMF- / AMF-Associated Expected UE behaviour parameters from UDM for the specific UE / a group of UEs, PDU session, PDU set, application. For the case of AMF provided RRC Inactive Assistance Information: In certain embodiments of the present disclosure, XR-specific traffic characteristics / parameters e.g., packet delay distribution / jitter information, periodicity information (e.g. PDU set periodicity, periodicity among PDUs in a PDU set), etc. may be used to formulate a RAN paging policy and strategy in RRC Inactive state. The AMF may use the XR-specific characteristics / parameters to decide UE-specific DRX values including extended idle mode DRX values such as cycle length, paging time window, etc. and may provide the XR-based UE-specific DRX values to NG-RAN during registration, service request, handover to assist the NG-RAN to decide whether the UE can be sent to RRC Inactive state or not. When the UE is CM-CONNECTED with RRC Inactive state, the UE may resume the RRC Connection due to periodicity of PDUs in a PDU set or periodicity of the PDU sets or expected packets due to packet delay distribution / jitter information specific to application traffic, such as XR application. Procedure Figure 2 shows an example procedure for UPF and / or NWDAF to derive / obtain XR and media traffic characteristics. The steps are described as follows: In Step 1 the AF either sends a request to reserve resources for an AF session using Nnef_AFsessionWithQoS_Create request message or may send a Nnef_AFsession\MthQoS_Update request message for an established AF session with required QoS and includes periodicity information (e.g. traffic / PDU set periodicity), data burst size, packet delay distribution / jitter related information including required packet delay distribution / jitter, jitter calculation parameter (e.g. packet delay distribution / jitter measurement averaging window / bin size / measurement period), etc. as part of QoS reference / QoS parameters to 5GC directly or via NEF. The information is then provided to PCF and / or TSCTSF. If the AF session can adjust to different QoS parameter combinations, the AF may provide Alternative Service Requirements in a prioritized order (indicating the preference of the QoS requirements with which the service can operate) in addition to the QoS Reference or individual QoS parameters. In addition to the existing individual parameters of requested 5GS delay and requested guaranteed flow bitrate to comprise each Requested Alternative QoS Parameter set, required packet delay distribution / jitter can also be considered as another individual parameter and can be used to determine the prioritization order of the Alternative Service Requirements. If the AF request is sent via the TSCTSF, the TSCTSF determines a Requested packet delay distribution / jitter considering the Requested 5GS Delay, jitter calculation parameter (e.g. packet delay distribution / jitter averaging window / bin size / measurement period) and the UE-DS-TT Residence Time. In Step 2 the PCF generates a PCC rule / the policy including traffic periodicity, packet delay distribution / jitter measurements along with the jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period), etc. and provides the policy to SMF. If no 5QI exists that matches the individual QoS parameters requested by the AF, the PCF generates a new dynamically assigned 5QI based on the individual QoS parameters. In case TSC Assistance Container is received from the TSN AF or TSCTSF, the PCF associates the container with the derived PCC rule QoS parameters that include XRM traffic characteristics e.g., packet delay distribution / jitter, periodicity information (PDU set periodicity, periodicity among PDUs in a PDU set), etc.. In Step 3 the SMF sends N4 session management procedures including QoS Monitoring, N4 reporting along with parameters related XRM traffic characteristics e.g., packet delay distribution / jitter, periodicity information (e.g. PDU set periodicity, periodicity among PDUs in a PDU set), etc. In order for 5G Core to derive XR and media traffic characteristics including traffic periodicity, data burst size, packet delay distribution / jitter information, in Step 4a, based on the information provided by SMF, the UPF may derive XR and media traffic characteristics. More specifically, UPF may obtain packet delay distribution / jitter information as, for example, minimum, maximum, mean and variance values based on the given jitter calculation parameter (e.g. averaging window / distribution calculation window / bin size / measurement period) and utilizes the performed packet delay measurement on N3 interface, NG-RAN, E2E and N6 interface. In addition to this, the UPF may obtain data burst arrival periodicity and / or data burst size along with PSER and PSDB. In Step 4b, UPF provides the observed XR and media traffic characteristics for the given time period as part of N4 reporting. The reporting from UPF can be threshold-based, event-based or periodic reporting where for threshold-based option, threshold may represent a jitter measurement value, percentage of change / change rate, and for event-based option, the threshold may represent percentage of change / change rate. Optionally, UPF / SMF may also provide the observed XR and media traffic characteristics to TSCTSF / AF where as shown in Step 4c, AF may update / adjustthe required QoS parameters and sends an Nnef_AFsessionWithQoS_Update request as noted in Step 1. In Step 5, SMF provides the XR and media traffic characteristics including burst periodicity as PDUs in a PDU set and / or PDU set periodicity, data burst size and / or size of PDU sets, packet delay distribution / jitter information to NG-RAN as part of existing RAN assistance information such as TSC (Time Sensitive Communication) Assistance Information, SMF derived CN assisted RAN parameters tuning, per established PDU Session, AMF provided RRC Inactive Assistance Information. In Step 6, based on the provided assistance information regarding XR and media traffic characteristics, NG-RAN optimizes existing and new procedures including power saving management i.e., CDRX, XR-aware capacity handling, etc. Various examples of the present disclose provide the following. In a first example, a method of a first network entity is provided, the method comprising: obtaining a packet delay measurement; obtaining a jitter calculation parameter; obtaining jitter information based on the packet delay measurement and the jitter calculation parameter; and transmitting the jitter information to a second network entity. In a second example, the method of the first example is provided, wherein the jitter calculation parameter is one of an averaging window, a distribution calculation window, a bin size, and a measurement period. In a third example, the method of the first or second example is provided, wherein obtaining the jitter calculation parameter comprises receiving, from the second network entity or a third network entity, the jitter calculation parameter. In a fourth example, the method of the first or second example is provided, wherein obtaining the jitter calculation parameter comprises determining, at the first network entity, the jitter calculation parameter. In a fifth example, the method of the fourth example is provided, wherein determining the jitter calculation parameter comprises determining the jitter calculation parameter based on at least one of: an extended reality traffic characteristic, a media traffic characteristic, a periodicity, a data burst time, a data burst arrival time, a traffic direction, and a predetermined or preconfigured jitter calculation parameter value. In a sixth example, the method of any of the first to fifth examples is provided, wherein the first network entity is a core network entity. In a seventh example, the method of any of the first to sixth examples is provided, wherein the first network entity is one of a User Plane Function (UPF) entity, a Session Management Function (SMF) entity, and a Policy Control Function (PCF) entity. In an eighth example, the method of any of the first to fifth examples is provided, wherein the first network entity is a Radio Access Network (RAN) entity. In a ninth example, the method of any of the first to eighth examples is provided, wherein the second network entity is a Session Management Function (SMF) entity (or any other suitable core network entity). In a tenth example, the method of any of the first to sixth examples is provided, wherein the first network entity is a UPF entity; wherein obtaining a packet delay measurement comprises performing packet delay measurements on the N6 interface; and wherein obtaining the jitter information comprises obtaining the jitter information based on the packet delay measurements for the N6 interface. In an eleventh example, the method of any of the first to sixth or tenth examples is provided, wherein the first network entity is a UPF entity; wherein the method further comprises receiving, from the SMF, a quality of service (QoS) monitoring policy comprising a usage reporting rule (URR); wherein the URR comprises QoS parameters including at least one of packet delay distribution / jitterto be monitored, reporting threshold as a measurement value or a percentage of change / change rate, relevant action, and event report for specific QoS flows. In a twelfth example, the method of the eleventh example is provided, wherein transmitting the jitter information to the second network entity comprises transmitting the jitter information to the SMF when an event report is triggered based on the QoS parameters in the URR. In a thirteenth example, a method of a core network entity is provided, the method comprising obtaining jitter information; and transmitting radio access network (RAN) assistance information to a RAN, the RAN assistance information comprising the jitter information. In a fourteenth example, the method of the thirteenth example is provided, wherein obtaining jitter information comprises receiving the jitter information from another core network entity. In a fifteenth example, the method of the fourteenth example is provided, wherein the jitter information is received from an application function (AF) entity. In a sixteenth example, the method of any of the thirteenth to fifteenth examples is provided, wherein the core network entity is a Session Management Function (SMF) entity. In a seventeenth example, a network entity is provided, wherein the network entity is configured to perform the method of any of the first to sixteenth examples. In an eighteenth example, a computer program is provided, the computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any of the first to sixteenth examples. In a nineteenth example, a computer or processor-readable data carrier is provided, the computer or processor-readable data carrier having stored thereon a computer program according to the eighteenth example. Figure 3 is a block diagram of an exemplary network entity that may be used in examples of the present disclosure. For example, a UE, base station (e.g. gNB, eNB, RAN) and / or other network entity (e.g. UPF, AMF, SMF, PCF / NEF / TSCTSF, AF) in the examples of Figures 1 and 2 may comprise an entity of Figure 3. The skilled person will appreciate that a network 5 entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The entity 300 comprises a processor (or controller) 301, a transmitter 303 and a receiver 305. The receiver 305 is configured for receiving one or more messages from one or more other 10 network entities, for example as described above. The transmitter 303 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 301 is configured for performing one or more operations, for example according to the operations as described above. Abbreviations / Definitions In the present disclosure, the following abbreviations and definitions may be used. 3GPP 5G 5GC 5QI AF AMF AR CDRX CM CN DL DNN DRX GBR gNB GPRS GTP-U HDRLL MR N3 N4 N6 N9 NEF NF NR NWDAF 0AM PCF PDB PDCCH PDCP PDU PSDB PSER QFI QoS RAN RAN2 Rei RLC RTT RRC SA SBA SMF S-NSSAI SUPI TR TS TSC TSCAI TSCTSF TSN UE UL UPF URLLC URR Uu VR XR XRM 3rd Generation Partnership Project 5th Generation 5G Core 5G QoS Identifier Application Function Access and Mobility Management Function Augmented reality Connected Mode Discontinuous Reception Connected Mode Core Network Downlink Data Network Name Discontinuous Reception Guaranteed Bit Rate 5G base station General Packet Radio Service GPRS Tunnelling Protocol High Data Rate Low Latency Mixed Reality Interface between 5G RAN and UPF Interface between Control Plane and User Plane Interface between UPF and AF / DN Interface between two UPFs Network Exposure Function Network Function New Radio Network Data Analytics Function Operations, Administration, and Maintenance Policy Control Function Packet Delay Budget Physical Downlink Control Channel Packet Data Conversion Protocol Protocol Data Unit PDU-Set Delay Budget PDU-Set Error Rate QoS Flow Identifier Quality of Service Radio Access Network Radio layer 2 and Radio layer 3 Working Group Release Radio Link Control Round-Trip Transmission Radio Resource Control Stand-Alone Service-Based Architecture Session Management Function Single Network Slice Selection Assistance Information Subscription Permanent Identifier Technical Report Technical Specification Time Sensitive Communications TSC Assistance Information Time Sensitive Communication and Time Synchronization Function Time Sensitive Networking User Equipment Uplink User Plane Function Ultra Relaible Low Latency Communication Usage Reporting Rule Air interface between terminal and base station / access point Virtual Reality Extended Reality XR and media

Claims

1. A method of a Session Management Function (SMF), the method comprising:transmitting, to a User Plane Function (UPF), traffic periodicity information;receiving, from the UPF, jitter information obtained by the UPF based on the traffic periodicity information and a packet delay measurement performed by the UPF; andtransmitting RAN assistance information comprising the jitter information and the traffic periodicity information to a Radio Access Network (RAN), wherein the RAN assistance information is for configuring a Connected Mode Discontinuous Reception (CDRX) procedure.

2. A method of a wireless communication network, the method comprising:transmitting, by an SMF to a UPF, traffic periodicity information;receiving, at the SMF from the UPF, jitter information obtained by the UPF based on the traffic periodicity information and a packet delay measurement performed by the UPF; and transmitting, by the SMF to a RAN, RAN assistance information comprising the jitter information and the traffic periodicity information;wherein the RAN assistance information is for configuring a Connected Mode Discontinuous Reception (CDRX) procedure3. The method of claim 1 or 2, wherein the jitter information is N6 jitter information.

4. The method of any preceding claim, wherein the RAN assistance information isprovided to the RAN via Time Sensitive Communication Assistance Information (TSCAI).

5. The method of any preceding claim, wherein the jitter information and the trafficperiodicity information relate to Extended Reality and Media (XRM) services.

6. A network entity configured to perform a method according to any preceding claim.

7. A computer program comprising instructions which, when the program is executed bya computer or processor, cause the computer or processor to carry out a method according to any of claims 1 to 5.

8. A computer or processor-readable data carrier having stored thereon a computer program according to claim 7.

Images