Patent Description:
As the cellular system including the <NUM> network supports an increasing number of devices and services including applications with a wide range of use cases and diverse needs with respect to bandwidth, latency, and reliability requirements, the cellular system may need to prioritize resources across the wireless access network and the core network (and/or for example, prioritizing across the control plane and the user plane) to support differentiation among different service data flows (SDFs). Moreover, the associated quality of service (QoS) requirements may be dynamic. As such, flexible and efficient QoS control mechanisms may enable establishment, modification, and/or enforcement of the QoS requirements, examples of which include maximum bit rate, guaranteed bit rate, priority level, packet delay budget, packet loss rate, and/or other QoS parameters. Document <CIT> relates to a method of managing or securing quality of service of uplink and an apparatus therefor. For example, a method of managing quality of service (QoS) of an uplink of a terminal includes the steps of: when the terminal supports reflective QoS, transmitting an instruction regarding the reflective QoS to a network node; and receiving from the network node an instruction on whether the reflective QoS is to be applied in response to the instruction regarding the reflective QoS.

Like labels are used to refer to same or similar items in the drawings.

Reflective QoS support is a QoS control mechanism allowing a user equipment (UE) to derive, based on the received the downlink (DL) traffic from the core network, a QoS rule, when the UE reflective QoS function is enabled by the network. However, there is a need in <NUM> to provide support for reflective QoS including related signaling and encoding of QoS related information.

In some example embodiments, there may be provided a UE session management (SM) capability negotiation. In some example embodiments, there may be provided encoding and/or signaling of QoS classification and marking rules to the UE. Moreover, there may be provided a mechanism for signaling the UE session management capabilities to the network. Alternatively or additionally, there may be provided an enhancement to the packet data unit (PDU) session establishment request message to support UE session management capability signaling. Alternatively or additionally, there may be provided signaling for supporting reflective QoS capability negotiation.

Mobility management (MM) and session management (SM) may be considered two functions handled by the non-access stratum (NAS) between the user equipment and the core network. In the <NUM> system, the mobility management function and the session management function may be managed by the same core network node, such as the mobility management entity (MME) which in the case of LTE handles mobility management and session management. To support home routed roaming, gateway core network (GWCN) sharing, and/or other <NUM> features, the <NUM> system's mobility management function and session management may be separated into two standalone functions (for example, at two different nodes). For <NUM> mobility management, an access and mobility management function (AMF) node may provide UE access and mobility management functions including UE registration/deregistration, UE location reachability, and/or the like as defined, for example, in 3GPP TS <NUM>. In <NUM>, session management may be provided by a session management function (SMF) for the end-to-end control functions on packet data unit (PDU) sessions as defined, for example, in 3GPP TS <NUM>. Moreover, the session management messages may be transferred via the AMF and terminated at the SMF. Accordingly, there may be a need for the UE to send its session management capability separately to the SMF for session management capability negotiation.

<FIG> depicts an example of a portion of a <NUM> wireless network <NUM>, in accordance with some example embodiments. The <NUM> wireless network <NUM> may include a user equipment (UE) <NUM> configured to wirelessly couple to a radio access network (RAN) <NUM>, such as a base station and/or other type of wireless access point. The network <NUM> may include a core network, which may include an AMF <NUM>, an SMF <NUM>, a policy control function (PCF) <NUM>, and a user plane function (UPF) <NUM>. The network <NUM> may also couple to other nodes and networks, such as a data network (DN) <NUM>. <FIG> also depicts service interfaces, such as N1, N2, N3, N4, N6, N7, N11, N15, and/or the like. The architecture and the service interfaces may be defined in accordance with a standard, such as 3GPP TS <NUM>.

<FIG> depicts an example of a signaling flow <NUM> for the UE <NUM> to signal to the network the UE's session management capabilities, in accordance with some example embodiments. In some example embodiments, the UE may negotiate with the network the session management capabilities to be used by the UE by sending a message including an indication of at least one session management capability (for example, a service or capability to be provided as part of the network's session management of a packet data unit session) requested from the network. The network may respond, as part of the negotiation, with an acceptance of the requested at least one session management capability if the network can support (or agrees to provide) the requested at least one session management capability. The session management capabilities of the UE refer to, for example, those capabilities supported by the UE with respect to session management, examples of which include reflective QoS (RQoS), ultra-reliable low latency communications (URLLC), and/or the like.

During, for example, the packet data unit (PDU) session establishment, the UE <NUM> may send, at <NUM>, a message, such as a NAS message, to the AMF <NUM>, in accordance with some example embodiments. The message sent at <NUM> may include a PDU session establishment request as part of the N1 session management information. In accordance with some example embodiments, the UE may indicate support of a UE SM capability, such as RQoS or other UE SM capability (for example, "cap-A"). This UE SM capability may be signaled to the network using an information element (IE) in a message <NUM>. An example of this information element is the "UE_SM_capabilty" which in this example carries a UE SM capability supported indication (for example, "RQoS-supportedInd" or "cap-A SupportedInd") at message <NUM>. The access network <NUM> may encapsulate the NAS message sent, at <NUM>, in a N2 message sent towards the AMF <NUM>.

The AMF <NUM> may determine that the message <NUM> corresponds to a request for a new PDU session. When this is the case, the AMF may select, at <NUM>, an SMF <NUM> (for example, from a plurality of SMFs). At <NUM>, the AMF may then forward, to the selected SMF <NUM>, the PDU session establishment request including the UE_SM_capabilty information element including a UE SM capability indication (for example "RQoS-supportedInd" or "cap-A SupportedInd").

The SMF <NUM> may perform, at <NUM>, PCF <NUM> selection and obtain, at <NUM>, dynamic policy and charging control (PCC) or obtain default PCC rules for the PDU session based on location policy. At <NUM>, the SMF may initiate an N4 session establishment with the UPF <NUM> (which may be selected at <NUM>).

In accordance with some example embodiments, the SMF <NUM> may send, at <NUM>, to the AMF <NUM> a PDU session establishment accept message, which may include the N2 SM information. If the UE SM capability (which was requested by the UE at <NUM>) is supported by the network, the SMF may also include the UE SM capability indication and/or related UE SM parameters. In the example of <FIG>, the SM parameters are indicated by "cap-A parameters" for the request SM capability A; the (cap-A) specific service parameters for realizing the cap-A service (which were requested by the UE as part of the PDU session establishment request). For example, the SMF may include an "RQoS-supportedInd" or an RQoS parameter, such as an RQoS timer value toward the UE. At <NUM>, the AMF <NUM> may send to the radio access network <NUM> (labeled NG-RAN) a PDU session resource setup request including the N2 UE SM capability indications (for example, "RQoS-supportedInd", or "cap-A SupportedInd"), N2 UE SM capability parameters (for example, RQoS timer value or "cap-A parameter"), and PDU session establishment accept message.

At <NUM>, the radio access network <NUM> may initiate an access-specific signaling exchange (for example, via radio resource control) with the UE <NUM> to allocate radio access network resources for the QoS flows indicated in the authorized QoS rules and the RAN N3 tunnel information for the PDU session.

At <NUM>, if the resource allocation is successful, the radio access network <NUM> may forward, in accordance with some example embodiments, the PDU session establishment accept message to the UE. The UE may determine whether the SM capability is supported or not by the explicit presence of SM capability support indication or SM capability related parameters (for example, "cap-A parameters) carried by the message at <NUM>.

To illustrate by way of an example, the UE <NUM> may receive at <NUM> a capability parameter corresponding to a reflective QoS (RQoS) timer value, which may be received in response to the UE <NUM> sending, at <NUM>, the cap-A SupportedInd corresponding to the RQoS supported at the UE.

At <NUM>, the radio access network <NUM> may send to the AMF <NUM> the PDU session resource setup response message with the N2 SM information. At <NUM>, the AMF may forward N2 SM information from access network to the SMF <NUM> in an Nsmf_PDUSession_UpdateSMContext request message. The PDU session may be established.

The UE session management capability information element (as shown for example at <NUM> and <NUM> at <FIG>) may signal the UE's capabilities related to PDU session management. In some example embodiments, this information element may code (as a type <NUM> information element) the UE's SM capability. When this is the case, the UE session management capability information may provide up to <NUM> UE session management capability indications.

<FIG> depicts an example of the UE SM capability information element carried in the first <NUM> bits of an octet, in accordance with some example embodiments. As shown at <FIG>, when the first bit (labeled Cap#1Ind) is a <NUM>, this may signal that the <NUM>st SM capability is not supported by the UE, but a value of <NUM> may indicate that the <NUM>st SM capability is supported by the UE. Likewise, when the second bit (labeled Cap#2Ind) is a <NUM>, this may signal that the <NUM>nd SM capability is not supported by the UE, but a value of <NUM> may indicate that the <NUM>nd SM capability is supported by the UE. In the example of <FIG>, the bits <NUM> and <NUM> are used as spares but may be used to signal UE support for additional SM capabilities as well. Table <NUM> below summarizes the UE SM capability information element of <FIG>. Bits <NUM>-<NUM> may be used to carry the UE SM capability IEI, which is used to identify the information element in the message.

In some example embodiments, the UE session management capability information element may signal the UE's capabilities related to PDU session management as a type <NUM> information element. When this is the case, the UE session management capability information may provide up to <NUM> UE session management capability indications. For example, the UE SM capability in the type <NUM> implementation may have a minimum length of <NUM> octets and a maximum length of <NUM> octets.

<FIG> depicts an example of the type <NUM> UE session management capability information element, in accordance with some example embodiments. In the example of <FIG>, octets <NUM>-<NUM> may carry the UE's SM capabilities (which are related to PDU session management). In the example of <FIG>, the <NUM>st octet includes the UE SM capability IEI and the <NUM>nd octet includes an indication of the length of the contents, such as whether the message will be <NUM>, <NUM>, or <NUM> octets in length. The <NUM>rd - <NUM>th octets may be used to carry the SM capability indicators. In the example of <FIG>, only the <NUM>rd octet is used, although other quantities of octets may be used as well. As shown at <FIG> and summarized in Table <NUM> below, when the <NUM>st bit (labeled Cap#1Ind) is a <NUM>, this may signal that the <NUM>st SM capability is not supported by the UE, but a value of <NUM> may indicate that the <NUM>st SM capability is supported by the UE. When the <NUM>nd bit (labeled Cap#2Ind) is a <NUM>, this may signal that the <NUM>nd SM capability is not supported by the UE, but a value of <NUM> may indicate that the <NUM>nd SM capability is supported by the UE.

The PDU session establishment request message sent, at <NUM>, by the UE to the network may initiate establishment of a PDU session. The UE SM capability information element (e.g., UE_SM_capability) may be included in the message <NUM>, when the UE requests establishment of a new PDU session of type "IP", "IPv4", "IPv6" or "Ethernet" and the UE supports Reflective QoS. Table <NUM> below depicts an example of a PDU session establishment request message including a PDU session identifier (ID), a PDU session type, and the UE_SM_capability information element. The UE_SM_capability information element may have the same coding scheme as noted above with respect to Tables <NUM> and <NUM> above.

In some example embodiments, there may be provided a network session management capability information element to enable signaling of a network response to the UE requested SM capabilities. The network session management capability information element may be coded, as a type <NUM> information element, to provide up to <NUM> session management capability indications. <FIG> depicts an example of an octet for the network session management capability information element, and Table X below summarizes its operation.

Alternatively or additionally, the network session management capability information element may be coded, as a type <NUM> information element, to provide up to <NUM> session management capability indications. <FIG> depicts an example implementation for the network session management capability information element, and Table X2 below summarizes its operation. In the example of <FIG>, the network SM capability support IE may have a minimum length of <NUM> octets and a maximum length of <NUM> octets.

In some example, embodiments, the PDU session establishment accept message (see, e.g., <NUM>) may indicate a successful establishment of a PDU session. The PDU session establishment accept message may include a network SM capability support information element to inform the UE of the set of session management capabilities that the network supports, which may include the SM capabilities requested by the UE via UE SM capability IE in the PDU SESSION ESTABLISHMENT REQUEST message.

If the network sends capabilities parameters (or additional capabilities parameters) to the UE, then the network may not explicit signal support of the UE requested SM capabilities as capability parameters sent by the network can be used as an implicit indication that the network supports and enables the requested SM capability. Moreover, some session management services may not require special UE capabilities or may not require an explicit UE request for the service to be enabled. Table <NUM> below depicts the contents of the PDU session establishment accept message including a network SM capability support information element, in accordance with some example embodiments. Table <NUM> depicts another implementation of the contents of the PDU session establishment accept message including a network SM capability support information element, in accordance with some example embodiments.

In some example embodiments, the UE may be configured to operate using reflective QoS. This reflective mode QoS may be applicable when a PDU session is of a PDU session type of "IP", "IPv4", "IPv6" and "Ethernet," for example. The reflective QoS may not be applicable when the PDU session is of a PDU session type of "unstructured," for example.

<FIG> depicts an example of a signaling flow <NUM> for the UE session management negotiation for reflective QoS support, in accordance with some example embodiments.

During the PDU session establishment, the UE <NUM> may send, at <NUM>, a NAS message including a PDU session establishment request within the N1 SM information, such as the UE_SM_capability. If the UE supports the reflective QoS, the UE may indicate in the UE_SM_capability information element support of the reflective QoS capability as shown by the indicator <NUM> (labeled "RQoS supported"). The NAS message sent at <NUM> may be encapsulated, by the access network <NUM>, in an N2 message towards the AMF <NUM>.

When the AMF <NUM> determines the message corresponds to a request for a new PDU Session, the AMF may select, at <NUM>, an SMF <NUM>. The AMF may forward, at <NUM>, to the SMF <NUM> the PDU session establishment request including the UE_SM_capability having the RQoS supported, in accordance with some example embodiments.

At <NUM>, the SMF <NUM> may perform PCF selection and obtain, at <NUM>, dynamic PCC or may obtain default PCC rules for the PDU session based on location policy.

At <NUM>, the SMF <NUM> may perform service data flow (SDF) binding and may mark reflective QoS supported, in accordance with some example embodiments. The SMF may also send to the UE the reflective QoS (RQoS) timer value, in accordance with some example embodiments. Furthermore, the SMF may send, at <NUM>, to the UPF <NUM> (which may be selected at <NUM>) the RQoS supported indication, when initiating N4 session establishment.

At <NUM>, the SMF <NUM> may send to AMF <NUM> a PDU session establishment accept message including the RQoS timer value and N2 SM information having a QoS profile including RQoS attributes as well as other QoS attributes. At <NUM>, the AMF <NUM> may send to access network <NUM> a PDU session resource setup request including the RQoS timer value and N2 SM information having a QoS profile including RQoS attributes as well as other QoS attributes.

At <NUM>, the access network <NUM> may initiate access specific signaling exchange with the UE <NUM> to allocate the necessary radio access network resources for QoS flows indicated in the authorized QoS rules and RAN N3 tunnel information for the PDU session. If resource allocation is successful, the access network <NUM> may, at <NUM>, forward to the UE <NUM> the PDU session establishment accept message including the RQoS timer values and/or the like. The UE <NUM> may then determine that RQoS is enabled at the UE, and may store, at <NUM>, the RQoS timer value.

At <NUM>, the access network <NUM> may send to AMF <NUM> a PDU session resource setup response message including N2 SM information. The AMF may forward, at <NUM>, the N2 SM information to the SMF via a message, such as an Nsmf_PDUSession_UpdateSMContext request message. The PDU session may be established, at <NUM>, with reflective QoS enabled.

In some example embodiments, the UE SM capability information element (UE_SM_capability) may carry an indicator, such as indicator <NUM>, which may be implemented using at least a bit, to signal whether the UE supports reflective QoS during the UE PDU session establishment. <FIG> depicts an example implementation of the UE_SM_capability information element including, at bit <NUM>, the RQoS supported indicator <NUM>. For example, if the RQoS has a value of "<NUM>" it may indicate that reflective QoS is supported or enable, while a value of "<NUM>" may indicate that reflective QoS is not supported or enabled at the UE. Table <NUM> below lists a summary of the UE SM capability information element of <FIG>.

<FIG> depicts another example implementation of the UE_SM_capability information element including. Table Z below lists a summary of the UE SM capability information element of <FIG>. Table Z1 depicts an example of a PDU session establishment accept message including at least one capabilities parameter, such as the RQoS timer value provided by the network to the UE.

Table Z: UE SM capability information element.

<FIG> depicts authorized QoS rules signaling <NUM> for enabling the UE <NUM> to obtain authorized QoS rules from the network, in accordance with some example embodiments.

During the PDU session establishment, the UE <NUM> may send, at <NUM>, a NAS message including a PDU session establishment request as part of the N1 SM information. The PDU session establishment request may include the UE's SM capability information element (UE_SM_capability), in accordance with some example embodiments. The NAS message sent by the UE may be encapsulated by the access network <NUM> in a N2 message towards the AMF.

When the AMF <NUM> determines that the message received at <NUM> corresponds to a request for a new PDU session, the AMF may select, at <NUM>, an SMF <NUM>. The AMF <NUM> may forward, at <NUM>, the PDU session establishment request to the SMF <NUM>.

At <NUM>, the SMF may perform PCF selection and may obtain, at <NUM>, dynamic PCC or the default PCC rules for the PDU session by location policy. At <NUM>, the SMF <NUM> may perform binding of the SDF to QoS flows, and the SMF <NUM> may generate QoS rules for the UE (including packet filters and QoS parameters). The SMF <NUM> may then initiate, at <NUM>, N4 Session establishment with the UPF <NUM> selected at <NUM>.

In some example embodiments, the SMF <NUM> may send, a <NUM>, to the AMF <NUM> a PDU session establishment accept message including authorized QoS rules, session-aggregate maximum bit rate (AMBR) information, and N2 SM information, which may further include a QoS profile (e.g., a QoS parameters and the like). At <NUM>, the AMF <NUM> may send to the access network <NUM> a PDU session resource setup request message including authorized QoS rules, session-aggregate maximum bit rate (AMBR) information, and N2 SM information (which may include QoS profiles, QoS parameters, and/or the like).

At <NUM>, the access network <NUM> may initiate an access specific signaling exchange with the UE <NUM> to allocate the necessary RAN resources for QoS flows <NUM> indicated in the authorized QoS rules and RAN N3 tunnel information for the PDU session. At <NUM>, if resource allocation is successful, the access network <NUM> may forward to the UE <NUM> the PDU session establishment accept message including the authorized QoS rules, AMBR information, and/or other SM information, in accordance with some example embodiments.

At <NUM>, the access network <NUM> may send to the AMF <NUM> a PDU session resource setup response message including the N2 SM information on RAN tunnel information and, in accordance with some example, embodiments, a list of accepted or rejected QoS profile(s). At <NUM>, the AMF <NUM> may forward to the SMF <NUM> the N2 SM information including a list of accepted or rejected QoS profile(s). The AMF may forward this information in an Nsmf_PDUSession_UpdateSMContext request message. At <NUM>, the PDU session may be established.

In some example embodiments, there may be provided information elements for QoS rules to specify the set of authorized parameters used by the UE for classification and marking of uplink user traffic. In some example embodiments, the QoS rules may include at least one packet filter for the uplink direction. The packet filter(s) may determine traffic mapping to QoS flows. In some example embodiments, the QoS rules information element may be a type <NUM> information element having a minimum length of <NUM> octets and a maximum length of <NUM>,<NUM> octets.

<FIG> depict examples of information elements associated with QoS rules, in accordance with some example embodiments.

Referring to <FIG>, the QoS rules information element may be carried in messages, such as messages <NUM>, <NUM>, and <NUM> of <FIG>. The QoS rules may include at the <NUM>st octet a QoS rules IEI, at the <NUM>nd and <NUM>rd octets an indication of the length in octets of the QoS rules information element, and at the <NUM>th octet through xth octet may include QoS rules <NUM> through n 360A-360N.

<FIG> depicts a given QoS rule 360A, in accordance with some example embodiments, The QoS rule 360A may include a QoS rule identifier 370A (octet <NUM>) to identify the QoS rule. Alternatively or additionally, the QoS rule 360A may include (octets <NUM>-<NUM>) a length 370B value to indicate the length in octets of the QoS rule 360A. Alternatively or additionally, the QoS rule 360A may include a QoS rule precedence 370C (octet <NUM>). The QoS rule precedence field may be used to specify the precedence of the QoS rule among other QoS rules associated with the QoS flow associated with the QoS rule 360A. For example, the higher the value of the QoS rule precedence field, the lower the precedence of that QoS rule. Alternatively or additionally, the QoS rule 360A may include a QoS flow identifier 370D (octet <NUM>). The QoS flow identifier field may be used to identify the QoS flow.

Alternatively or additionally, the QoS rule 360A may include a rule operation code 370E (octet <NUM>), which may be at bits <NUM>-<NUM>. Table <NUM> below depicts examples of rule operation codes.

Referring to Table <NUM>, if the rule operation code is set to "Ignore this IE" and the E bit 370F and the number of packet filters to zero, then the network may ignore the contents of the QoS rule flow template information element.

Referring again to <FIG>, the QoS rule 360A may include an E bit 370F (bit <NUM> of octet <NUM>). The E bit may indicate if a parameters list is included in the QoS rule information element. The E bit may be encoded so that a value of <NUM> means the parameters list is not included, while a value of <NUM> means a parameters list is included.

Alternatively or additionally, the QoS rule 360A may include a Number of packet filters <NUM> (octet <NUM>). The number of packet filters contains the binary coding for the number of packet filters in the packet filter list. The number of packet filters field may be encoded in bits <NUM> through <NUM> of octet <NUM>, wherein bit <NUM> is the most significant and bit <NUM> is the least significant bit. For the "delete existing QoS rule" operation and for the "no packet filter operation", the number of packet filters may be coded as <NUM>. For all other operations, the number of packet filters may be greater than <NUM> and less than or equal to <NUM>.

Alternatively or additionally, the QoS rule 360A may include the packet filter list <NUM>-I (octets <NUM> to z). The packet filter list may include a variable number of uplink packet filters. For the "delete existing QoS rule" operation and the "no packet filter operation," the packet filter list may be empty.

For the "delete packet filters from existing QoS rule" operation, the packet filter list may include a variable number of packet filter identifiers. This variable number may be derived from the coding of the number of packet filters <NUM>. For the "create new QoS rule" operation, the packet filter list may contain <NUM> or a variable number of packet filters. This variable number may be derived from the coding of the number of packet filters field <NUM>. For the "add packet filters to existing QoS rule" and "replace packet filters in existing QoS rule" operations, the packet filter list may contain a variable number of packet filters. This variable number may be derived from the coding of the number of packet filters field <NUM>.

<FIG> depicts a packet filter list <NUM>, when the rule operation is delete packets from existing QoS rules in accordance with some example embodiments. <FIG> depicts a packet filter list <NUM> in accordance with some example embodiments, when the rule operation is create a new QoS rule, add packet filter to an existing QoS rule, and/or replace a packet filter in an existing QoS rules. Each packet filter may be of a variable length, and each packet filter may include a packet filter identifier (<NUM> bits); a packet filter evaluation precedence (<NUM> octet); the length of the packet filter contents (<NUM> octet); and/or the packet filter contents itself (v octets).

The packet filter identifier field may be used to identify each packet filter in a QoS rule. The least significant <NUM> bits can be used. The packet filter evaluation precedence field may be used to specify the precedence for the packet filter among all packet filters in the QoS rule. Higher the value of the packet filter evaluation precedence field, lower the precedence of that packet filter is. The first bit in transmission order may the most significant bit. The length of the packet filter contents field may include the binary coded representation of the length of the packet filter contents field of a packet filter. The first bit in transmission order may be the most significant bit. The packet filter contents field may be of variable size and contains a variable number (at least one) of packet filter components. Each packet filter component may be encoded as a sequence of a one octet packet filter component type identifier and a fixed length packet filter component value field. The packet filter component type identifier may be transmitted first. In each packet filter, there may be not more than one occurrence of each packet filter component type. Among the "IPv4 remote address type" and "IPv6 remote address type" packet filter components, only one may be present in one packet filter. Among the "single local port type" and "local port range type" packet filter components, only one may be present in one packet filter. Among the "single remote port type" and "remote port range type" packet filter components, only one may be present in one packet filter. In the context of the packet filters, the term local refers to the UE and the term remote refers to an external network entity.

Referring to <FIG>, the packet filter identifier 389A-C field may be used to identify each packet filter in a QoS rule. The least significant <NUM> bits may be used as shown as shown in <FIG> to carry the packet filter identifier 389A-C. The packet filter evaluation precedence 390A-C field may be used to specify the precedence for the packet filter among all packet filters in the QoS rule. For example, the higher the value of the packet filter evaluation precedence field, the lower the precedence of that packet filter. The first bit in transmission order may be the most significant bit. The length of the packet filter contents 392A-C field may include the binary coded representation of the length of the packet filter contents field of a packet filter. The first bit in transmission order may be the most significant bit. The packet filter contents 394A-C field may be of variable size and may include at least one packet filter component. Each packet filter component may be encoded as a sequence of a one octet packet filter component type identifier and a fixed length packet filter component value field. The packet filter component type identifier may be transmitted first. In each packet filter, there may not be more than one occurrence of each packet filter component type. Among the "IPv4 remote address type" and "IPv6 remote address type" packet filter components, only one may be present in a single packet filter. Among the "single local port type" and "local port range type" packet filter components, only one may be present in single packet filter. Among the "single remote port type" and "remote port range type" packet filter components, only one may be present in a single packet filter (wherein local refers to the UE and the remote refers to an external network entity).

Table <NUM> lists example of packet filter component type identifiers, in accordance with some example embodiments. The packet filter contents (see, e.g., 394A, 394B OR 394C) field is of variable size and contains at least one packet filter component. Each packet filter component may be encoded as a sequence of a one octet packet filter component type identifier and a fixed length packet filter component value field. The packet filter component type identifier may be transmitted first.

Referring to Table <NUM>, for "IPv4 remote address type", the packet filter component value field may be encoded as a sequence of a four octet IPv4 address field and a four octet IPv4 address mask field. The IPv4 address field may be transmitted first. For "IPv4 local address type", the packet filter component value field may be encoded as defined for "IPv4 remote address type". Both the UE and network indication for support of the Local address in QoS rule may be required to use this packet filter component. For "IPv6 remote address type", the packet filter component value field may be encoded as a sequence of a sixteen octet IPv6 address field and a sixteen octet IPv6 address mask field. The IPv6 address field may be transmitted first. For "IPv6 remote address/prefix length type", the packet filter component value field may be encoded as a sequence of a sixteen octet IPv6 address field and one octet prefix length field. The IPv6 address field may be transmitted first. This parameter may be used, instead of IPv6 remote address type, when both the UE and network indication for support of the Local address in QoS rule are present. For "IPv6 local address/prefix length type", the packet filter component value field may be encoded as defined for "IPv6 remote address /prefix length". Both the UE and network indication for support of the Local address in QoS rule may be required to use this packet filter component.

For "Protocol identifier/Next header type", the packet filter component value field may be encoded as one octet which specifies the IPv4 protocol identifier or IPv6 next header.

For "Single local port type" and "Single remote port type", the packet filter component value field may be encoded as two octets specifying a port number. For "Local port range type" and "Remote port range type", the packet filter component value field may be encoded as a sequence of a two octet port range low limit field and a two octet port range high limit field. The port range low limit field may be transmitted first.

For "Security parameter index", the packet filter component value field may be encoded as four octets, which specifies the IPSec security parameter index. For "Type of service/Traffic class type", the packet filter component value field may be encoded as a sequence of a one octet Type-of-Service/Traffic Class field and a one octet Type-of-Service/Traffic Class mask field. The Type-of-Service/Traffic Class field may be transmitted first. For "Flow label type", the packet filter component value field may be encoded as three octets specifying the IPv6 flow label. The bits <NUM> through <NUM> of the first octet may be spare, while the remaining <NUM> bits may contain the IPv6 flow label. For "Destination MAC address type" and "Source MAC address type", the packet filter component value field may be encoded as <NUM> octets which specify a MAC address.

For "<NUM>. 1Q C-TAG VID type", the packet filter component value field may be encoded as two octets which specify the VID of the Customer-VLAN tag (C-TAG). The bits <NUM> through <NUM> of the first octet may be spare whereas the remaining <NUM> bits may contain the VID. For "<NUM>. 1Q S-TAG VID type", the packet filter component value field may be encoded as two octets which specify the VID of the Service-VLAN tag (S-TAG). The bits <NUM> through <NUM> of the first octet may be spare whereas the remaining <NUM> bits may contain the VID. For "<NUM>. 1Q C-TAG PCP/DEI type", the packet filter component value field may be encoded as one octet which specifies the <NUM>. 1Q C-TAG PCP and DEI. The bits <NUM> through <NUM> of the octet may be spare, the bits <NUM> through <NUM> contain the PCP and bit <NUM> contains the DEI. For "<NUM>. 1Q S-TAG PCP/DEI type", the packet filter component value field may be encoded as one octet which specifies the <NUM>. 1Q S-TAG PCP. The bits <NUM> through <NUM> of the octet may be spare, the bits <NUM> through <NUM> contain the PCP and bit <NUM> contains the DEI. For "Ethertype type", the packet filter component value field may be encoded as two octets which specify an Ethertype.

<FIG> depicts an example of a parameters list (which may be located at octets z+<NUM> to v), in accordance with some example embodiments. The parameter list is part of the QoS rule, and is used to carry or provide QoS parameters to the UE, so the QoS flows that matched the packet filters will receive QoS treatment indicated in the parameters, such as GFBR uplink equals uplink guaranteed flow bit rate, MFBR downlink equals downlink maximum flow bit rate, and/or the like. The parameters list may include a variable number of parameters that may be transferred. If the parameters list is included, the E bit is set to <NUM>; otherwise, the E bit is set to <NUM>. Each parameter included in the parameters list is of variable length. Moreover, each parameter of the parameter list may include a parameter identifier (<NUM> octet); a length of the parameter contents (<NUM> octet); and/or the parameter contents itself (v octets). The parameter identifier field may be used to identify each parameter included in the parameters list, and may include a coding, such as hexadecimal coding, of the parameter identifier. The <NUM>th bit <NUM> of the parameter identifier field may be the most significant bit, while the <NUM>st bit may include the least significant bit. Examples of parameter identifiers include <NUM> (5QI), <NUM> (GFBR Uplink), <NUM> (GFBR Downlink), <NUM> (MFBR Uplink), and <NUM> (MFBR Downlink).

If the parameters list includes a parameter identifier that is not supported by the receiving entity, the corresponding parameter may be discarded. The length of parameter contents field may include the binary coded representation of the length of the parameter contents field. The first bit in transmission order may be the most significant bit.

When the parameter identifier indicates 5QI, the parameter contents field may include the binary representation of <NUM> QoS identifier that is one octet in length. When the parameter identifier indicates GFBR Uplink, the parameter contents field may include the binary representation of guaranteed flow bit rate for uplink that is four octets in length. When the parameter identifier indicates GFBR Downlink, the parameter contents field may include the binary representation of guaranteed flow bit rate for downlink that is four octets in length. When the parameter identifier indicates MFBR Uplink, the parameter contents field may include the binary representation of Maximum flow bit rate for uplink that is four octets in length. When the parameter identifier indicates MFBR Downlink, the parameter contents field may include the binary representation of Maximum flow bit rate for downlink that is four octets in length.

In some example embodiments, there may be provided a Session-AMBR information element to indicate the initial subscribed PDU session aggregate maximum bit rate when the UE establishes a PDU session or to indicate the new subscribed PDU session aggregate maximum bit rate if it is changed by the network. The Session-AMBR information element may be implemented as shown below in Table YY and XX. The Session-AMBR is a type <NUM> information element with a length of <NUM> octets.

In some example embodiments, the PDU session establishment accept message may include QoS rules, Session-AMBR, and other QoS parameters authorized by the network Table GG depicts an example implementation of the PDU session establishment accept message, in accordance with some example embodiments.

<FIG> depicts an example signaling flow <NUM> for obtaining derived QoS rules via reflective QoS, in accordance with some example embodiments. The UE <NUM> may have stored, at <NUM>, reflective QoS timer values, which it received from the network. Moreover, the UE may have authorized QoS rules including packet filters.

At <NUM>, the PDU session may be established with reflective QoS enabled, in accordance with some example embodiments. When the UPF <NUM> receives at <NUM> downlink packet(s) from the data network (DN) <NUM> for the corresponding PDU session, the UPF <NUM> may mark, at <NUM>, the packet(s) with RQoS indication bit set in packet encapsulation header, in accordance with some example embodiments. The UPF may forward, at <NUM>, the marked downlink packets to the access network <NUM>, in accordance with some example embodiments. The access network <NUM> may mark, at <NUM> that the downlink packets are subject to Reflective QoS. Upon receiving the downlink packet at <NUM>, the UE <NUM> may, at <NUM>, derive a quality flow indicator (QFI) and packet filters for the derived QoS rules as well as start the RQoS timer. The derived QoS rules may be used for uplink traffic to the network. The derived rules may include the QFI and the uplink packet filter, which is derived from the downlink packet header by using source IP information (for example, IP address, port, and/or the like). As long as RQoS timer is running and marking for the identified QoS flow is present, derived QoS rules can be used for uplink traffic QoS classification. Derived rules may include QFI and at least one uplink packet filter derived from the downlink packet header by using source IP information (IP address, port, etc.) as well as a default rule precedence value.

<FIG> depicts an example signaling flow <NUM> for derived QoS rules removed from the UE, in accordance with some example embodiments. The UE <NUM> may have stored, at <NUM>, reflective QoS timer values, which it received from the network. Moreover, the UE may have authorized QoS rules including packet filters.

At <NUM>, the PDU session may be established with the reflective QoS enabled, in accordance with some example embodiments. At <NUM>, the derived QoS rules may be used for uplink traffic and the RQoS timer may be started. In the example of <FIG>, the SDF has changed as there is no longer reflective QoS operations as indicated at 530A-C by the lack of an RQoS indication from the network. As shown, the UPF <NUM> did not set, at 530A, an RQoS indication bit in packet encapsulation header. If there is no RQoS indication in downlink packet for a period timer that is longer than RQoS timer 530C, the Reflective QoS timer may then expire, in which case the UE <NUM> derived QoS rules are removed, <NUM>, from the UE.

<FIG> illustrates a block diagram of an apparatus <NUM>, in accordance with some example embodiments.

The apparatus <NUM> may represent a user equipment, such as the user equipment <NUM>. Alternatively or additionally, portions of the apparatus <NUM> may provide a network node such as a base station, AMF, SMF, and/or the like. For example, the AMF and SMF may include a wired and/or wireless interface to other network nodes, at least one processor circuitry which may access program code to cause one or more operations discloses herein with respect to the AMF or SMF.

The apparatus <NUM> may include at least one antenna <NUM> in communication with a transmitter <NUM> and a receiver <NUM>. Alternatively transmit and receive antennas may be separate. The apparatus <NUM> may also include a processor <NUM> configured to provide signals to and receive signals from the transmitter and receiver, respectively, and to control the functioning of the apparatus. Processor <NUM> may be configured to control the functioning of the transmitter and receiver by effecting control signaling via electrical leads to the transmitter and receiver. Likewise, processor <NUM> may be configured to control other elements of apparatus <NUM> by effecting control signaling via electrical leads connecting processor <NUM> to the other elements, such as a display or a memory. The processor <NUM> may, for example, be embodied in a variety of ways including circuitry, at least one processing core, one or more microprocessors with accompanying digital signal processor(s), one or more processor(s) without an accompanying digital signal processor, one or more coprocessors, one or more multicore processors, one or more controllers, processing circuitry, one or more computers, various other processing elements including integrated circuits (for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and/or the like), or some combination thereof. Accordingly, although illustrated in <FIG> as a single processor, in some example embodiments the processor <NUM> may comprise a plurality of processors or processing cores.

The apparatus <NUM> may be capable of operating with one or more air interface standards, communication protocols, modulation types, access types, and/or the like. Signals sent and received by the processor <NUM> may include signaling information in accordance with an air interface standard of an applicable cellular system, and/or any number of different wireline or wireless networking techniques, comprising but not limited to Wi-Fi, wireless local access network (WLAN) techniques, such as Institute of Electrical and Electronics Engineers (IEEE) <NUM>, <NUM>, <NUM>, ADSL, DOCSIS, and/or the like. In addition, these signals may include speech data, user generated data, user requested data, and/or the like.

For example, the apparatus <NUM> and/or a cellular modem therein may be capable of operating in accordance with various first generation (<NUM>) communication protocols, second generation (<NUM> or <NUM>) communication protocols, third-generation (<NUM>) communication protocols, fourth-generation (<NUM>) communication protocols, fifthgeneration (<NUM>) communication protocols, Internet Protocol Multimedia Subsystem (IMS) communication protocols (for example, session initiation protocol (SIP) and/or the like. For example, the apparatus <NUM> may be capable of operating in accordance with <NUM> wireless communication protocols IS-<NUM>, Time Division Multiple Access TDMA, Global System for Mobile communications, GSM, IS-<NUM>, Code Division Multiple Access, CDMA, and/or the like. In addition, for example, the apparatus <NUM> may be capable of operating in accordance with <NUM> wireless communication protocols General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), and/or the like. Further, for example, the apparatus <NUM> may be capable of operating in accordance with <NUM> wireless communication protocols, such as Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access <NUM> (CDMA2000), Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), and/or the like. The apparatus <NUM> may be additionally capable of operating in accordance with <NUM> wireless communication protocols, such as Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and/or the like. Additionally, for example, the apparatus <NUM> may be capable of operating in accordance with <NUM> wireless communication protocols, such as LTE Advanced, <NUM>, and/or the like as well as similar wireless communication protocols that may be subsequently developed.

It is understood that the processor <NUM> may include circuitry for implementing audio/video and logic functions of apparatus <NUM>. For example, the processor <NUM> may comprise a digital signal processor device, a microprocessor device, an analog-to-digital converter, a digital-to-analog converter, and/or the like. Control and signal processing functions of the apparatus <NUM> may be allocated between these devices according to their respective capabilities. The processor <NUM> may additionally comprise an internal voice coder (VC) 20a, an internal data modem (DM) 20b, and/or the like. Further, the processor <NUM> may include functionality to operate one or more software programs, which may be stored in memory. In general, processor <NUM> and stored software instructions may be configured to cause apparatus <NUM> to perform actions. For example, processor <NUM> may be capable of operating a connectivity program, such as a web browser. The connectivity program may allow the apparatus <NUM> to transmit and receive web content, such as location-based content, according to a protocol, such as wireless application protocol, WAP, hypertext transfer protocol, HTTP, and/or the like.

Apparatus <NUM> may also comprise a user interface including, for example, an earphone or speaker <NUM>, a ringer <NUM>, a microphone <NUM>, a display <NUM>, a user input interface, and/or the like, which may be operationally coupled to the processor <NUM>. The display <NUM> may, as noted above, include a touch sensitive display, where a user may touch and/or gesture to make selections, enter values, and/or the like. The processor <NUM> may also include user interface circuitry configured to control at least some functions of one or more elements of the user interface, such as the speaker <NUM>, the ringer <NUM>, the microphone <NUM>, the display <NUM>, and/or the like. The processor <NUM> and/or user interface circuitry comprising the processor <NUM> may be configured to control one or more functions of one or more elements of the user interface through computer program instructions, for example, software and/or firmware, stored on a memory accessible to the processor <NUM>, for example, volatile memory <NUM>, non-volatile memory <NUM>, and/or the like. The apparatus <NUM> may include a battery for powering various circuits related to the mobile terminal, for example, a circuit to provide mechanical vibration as a detectable output. The user input interface may comprise devices allowing the apparatus <NUM> to receive data, such as a keypad <NUM> (which can be a virtual keyboard presented on display <NUM> or an externally coupled keyboard) and/or other input devices.

As shown in <FIG>, apparatus <NUM> may also include one or more mechanisms for sharing and/or obtaining data. For example, the apparatus <NUM> may include a short-range radio frequency (RF) transceiver and/or interrogator <NUM>, so data may be shared with and/or obtained from electronic devices in accordance with RF techniques. The apparatus <NUM> may include other short-range transceivers, such as an infrared (IR) transceiver <NUM>, a BluetoothTM (BT) transceiver <NUM> operating using BluetoothTM wireless technology, a wireless universal serial bus (USB) transceiver <NUM>, a BluetoothTM Low Energy transceiver, a ZigBee transceiver, an ANT transceiver, a cellular device-to-device transceiver, a wireless local area link transceiver, and/or any other short-range radio technology. Apparatus <NUM> and, in particular, the short-range transceiver may be capable of transmitting data to and/or receiving data from electronic devices within the proximity of the apparatus, such as within <NUM> meters, for example. The apparatus <NUM> including the Wi-Fi or wireless local area networking modem may also be capable of transmitting and/or receiving data from electronic devices according to various wireless networking techniques, including 6LoWpan, Wi-Fi, Wi-Fi low power, WLAN techniques such as IEEE <NUM> techniques, IEEE <NUM> techniques, IEEE <NUM> techniques, and/or the like.

The apparatus <NUM> may comprise memory, such as a subscriber identity module (SIM) <NUM>, a removable user identity module (R-UIM), an eUICC, an UICC, and/or the like, which may store information elements related to a mobile subscriber. In addition to the SIM, the apparatus <NUM> may include other removable and/or fixed memory. The apparatus <NUM> may include volatile memory <NUM> and/or non-volatile memory <NUM>. For example, volatile memory <NUM> may include Random Access Memory (RAM) including dynamic and/or static RAM, on-chip or off-chip cache memory, and/or the like. Non-volatile memory <NUM>, which may be embedded and/or removable, may include, for example, read-only memory, flash memory, magnetic storage devices, for example, hard disks, floppy disk drives, magnetic tape, optical disc drives and/or media, non-volatile random access memory (NVRAM), and/or the like. Like volatile memory <NUM>, non-volatile memory <NUM> may include a cache area for temporary storage of data. At least part of the volatile and/or non-volatile memory may be embedded in processor <NUM>. The memories may store one or more software programs, instructions, pieces of information, data, and/or the like which may be used by the apparatus for performing operations disclosed herein including forming, by a user equipment, a session establishment message including an indication of at least one session management capability supported by the user equipment; sending, by the user equipment, the session establishment message including the indication towards a session management function; and receiving, by the user equipment and from the session management function, a response indicative of whether the session management function and/or a corresponding network supports the at least one session management capability to enable the user equipment to operate in accordance with the at least one session management capability. Alternatively or additionally, the apparatus may be configured to cause receiving, at a session management function node and from a user equipment, the session establishment message including an indication of at least one session management capability supported by the user equipment; and sending, by the session management function node and to the user equipment, a response indicative of whether the session management function and/or a corresponding network supports the at least one session management capability to enable the user equipment.

The memories may comprise an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying apparatus <NUM>. The memories may comprise an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying apparatus <NUM>. In the example embodiment, the processor <NUM> may be configured using computer code stored at memory <NUM> and/or <NUM> to control and/or provide one or more aspects disclosed herein including forming, by a user equipment, a session establishment message including an indication of at least one session management capability supported by the user equipment; sending, by the user equipment, the session establishment message including the indication towards a session management function; and receiving, by the user equipment and from the session management function, a response indicative of whether the session management function and/or a corresponding network supports the at least one session management capability to enable the user equipment to operate in accordance with the at least one session management capability. Alternatively or additionally, the apparatus may be configured to cause receiving, at a session management function node and from a user equipment, the session establishment message including an indication of at least one session management capability supported by the user equipment; and sending, by the session management function node and to the user equipment, a response indicative of whether the session management function and/or a corresponding network supports the at least one session management capability to enable the user equipment.

Some of the embodiments disclosed herein may be implemented in software, hardware, application logic, or a combination of software, hardware, and application logic. The software, application logic, and/or hardware may reside on memory <NUM>, the control apparatus <NUM>, or electronic components, for example. In some example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any non-transitory media that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer or data processor circuitry, with examples depicted at <FIG>, computerreadable medium may comprise a non-transitory computer-readable storage medium that may be any media that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein may be enhanced session management.

Claim 1:
A method comprising:
forming, by a user equipment, a session establishment message including an indication of at least one session management capability supported by the user equipment, the session management capability being reflective quality of service;
sending, by the user equipment, the session establishment message including the indication towards a session management function (<NUM>); and
receiving, by the user equipment and from the session management function, a response indicative of whether the session management function enables the at least one session management capability to configure the user equipment to operate in accordance with the at least one session management capability (<NUM>), wherein the response includes a timer value for a timer associated with the reflective quality of service, the timer value being indicative of whether the session management function enables the reflective quality of service.