NETWORKS

RELATED APPLICATIONS

[0001] The present application claims the benefits of priority of U.S. Provisional Patent Application No. 62/842,776; entitled“ENFORCEMENT OF SERVICE GAP CONTROL IN WIRELESS COMMUNICATION NETWORKS”; and filed at the United States Patent and Trademark Office on May 3, 2019; the content of which is incorporated herein by reference.

TECHNICAL FIELD

[0002] The present description generally relates to wireless communications and wireless communication networks, and more particularly relates to signaling restriction management in wireless communication networks.

BACKGROUND

[0003] Various functions have been introduced in 3GPP to support enhanced cellular Internet of things (CIoT) and machine-to-machine (M2M) use cases. One of those mechanisms is service gap control (SGC) which makes it possible for operators to restrict frequent connectivity for mobile originated (MO) signaling and data transmissions to the network by defining a minimum time period when a user equipment (UE) is not allowed to initiate MO signaling and data transmissions. The SGC functionality has been specified for the Evolved Packet System (EPS) and in Rel-16, 3GPP will introduce CIoT support including SGC for the 5G System (5GS).

[0004] For SGC as specified for EPS, the Mobility Management Entity (MME) may apply restrictions to signaling initiated by the UE when not allowed according to service gap limits. Service Gap Control is modelled as a function in EPS Mobility Management where the logic is specified in the Mobility Management sublayer and related signaling is performed in the NAS EPS Mobility Management protocol layer. The prevention of MO signaling and data transmissions is performed either by restricting Mobility Management procedures, or by preventing the UE to enter CM-CONNECTED mode where MO signaling and data transmissions can be performed without possibility to restrict or control in the Mobility Management layer.

[0005] In general, the UE is not allowed to initiate MO signaling and data transmissions when a service gap timer, provided by the network to the UE and started upon the UE transitioning from the CM-CONNECTED mode to the CM-IDLE mode transition, is running in the UE. The exceptions to this restriction are that the UE is allowed to perform tracking area updating and connectivity requests when needed for priority and emergency services. These procedures belong to the Mobility Management sublayer and can be supervised for restrictions by the MME Mobility Management function.

[0006] Additionally, for reasons of specific functions where the UE needs to be reachable for network-initiated communication via paging, the UE can attach to the network without packet data network (PDN) connectivity. However, after allowing the UE to attach to the network without PDN connectivity, the UE will enter CM-CONNECTED mode and it will not be possible for Service Gap Control to supervise and restrict any MO signaling and data transmissions performed in a different layer than Mobility Management, e.g. EPS Session Management. Thus, it is not possible in this case to prevent the UE from initiating communication not normally allowed when a service gap timer is running.

[0007] In 3GPP, the specification does not allow the UE to perform the above-described communications scenario, but there is no specification of the handling in the network to control and restrict UEs that for various reasons do not adhere to the restrictions, as specification of possible network solutions would result in protocol layer violating dependencies. Any solution is therefore implementation specific with the drawbacks of function variation, insight and limited robustness that comes from a non-standardized solution. As the main reason for restricting non- allowed use is to handle non-standard compliant, faulty implemented, and/or non-supporting UEs, reliable handling of these UEs in the network is of high importance.

SUMMARY

[0008] As shown in Figures 1 and 2, in 5GS, the Non-Access Stratum (NAS) protocol is designed in a slightly different manner. Notably, in 5GS, signaling of 5GS NAS Session Management is not fully transparent to 5GS NAS Mobility Management in the AMF, but carried as containers in NAS Transport 5G Mobility Management (5GMM) messages. Information in the 5GMM message indicates what type of data/message is included in the container. This has been changed as the NAS 5GMM and NAS 5GSM protocols terminate in different network entities; the NAS 5GMM protocol terminates at the AMF while the NAS 5GSM protocol terminates at the Session Management Function (SMF), and the AMF needs to be able to route 5GSM messages to the correct SMF. The same principle applies for other types of AMF routed data/messages, e.g. SMS and LCS messages.

[0009] By enhancing the Service Gap Control in the AMF 5GMM layer compared to the corresponding EPS functionality and by using the available information in Uplink NAS Transport messages, it is possible to specify a solution where all required information to correctly separate allowed from non-allowed signaling within AMF/Mobility Management and thereby avoid implementation specific solutions that need to operate across protocol layers.

[0010] In the case when the UE is allowed to register to the network and thereby enter CM- CONNECTED mode, Service Gap Control can evaluate any signaling and data routed via the AMF in NAS transport messages by checking other information in the message to determine the contents of the 5GMM transparent container and if not allowed according to Service Gap restrictions, take appropriate action.

[0011] It is further proposed to add a specific reject/notification at restricted forwarding due to Service Gap Control by specification of a cause value sent to the UE in a Downlink NAS Transport message. A supporting UE can act on the provided reject/notification to avoid further attempts that will fail due to Service Gap Control. As an option, or as a step of escalation, the AMF can reject with a general 5GMM back-off timer or apply other measurements to stop/minimize impact from non-compliant or non-supporting UEs.

[0012] By introducing a standardized method for restricting non-allowed traffic due to Service Gap Control, a reliable and robust handling in the network is achieved. Specific reject/notification codes can be tested, and operation verified.

[0013] According to one aspect, some embodiments include a method performed by a core network node. The method generally comprises receiving an uplink message from a wireless device, the uplink message comprising a payload container to be forwarded toward a destination network node, obtaining information about a content of the payload container, determining that a service restriction for the wireless device is active, and upon determining that the service restriction for the wireless device is active, determining whether to forward the payload container toward the destination network node based, at least in part, on the information about the content of the payload container.

[0014] Determining that the service restriction for the wireless device is active may comprise determining that a service restriction timer associated with the wireless device is running.

[0015] The method may comprise, upon determining to forward the payload container toward the destination network node based, at least in part, on the information about the content of the payload container, forwarding the payload container toward the destination network node.

[0016] The method may comprise, upon determining to refrain from forwarding the payload container toward the destination network node based, at least in part, on the information about the content of the payload container, sending a downlink message to the wireless device, the downlink message comprising an information element indicating that the payload container was not forwarded toward the destination network node. The information element indicating that the payload container was not forwarded toward the destination network node may comprise a value indicating congestion, a value indicating that the payload container was not forwarded toward the destination network node, a value indicating that service restriction for the wireless device is active, or a value indicating that the payload container was not forwarded toward the destination network node because service restriction for the wireless device is active. The downlink message may comprise, or further comprise, a back-off timer value. The back-off timer value may indicate to the wireless device for how long the wireless device should refrain from transmitting further uplink messages (e.g., further uplink messages comprising payload container to be forwarded toward a destination network node). The downlink message may comprise, or further comprise, the payload container.

[0017] The information about the content of the payload container may comprise at least one of a payload container type, a request type, an identifier of a network slice, and an identifier of a data network.

[0018] The uplink message may be an uplink non-access stratum (NAS) transport message. The downlink message may be a downlink NAS transport message.

[0019] The core network node may be a network node implementing an Access and Mobility Management Function (AMF).

[0020] According to another aspect, some embodiments include a core network node adapted, configured, enabled, or otherwise operable, to perform one or more of the described core network node functionalities (e.g. actions, operations, steps, etc.).

[0021] The core network node may comprise one or more communication interfaces and processing circuitry operatively connected to the one or more communication interfaces. The one or more communication interfaces are configured to enable the core network node to communicate with one or more other core network nodes (e.g., via a core network communication interface), with one or more radio network nodes (e.g., via a radio access network communication interface), and/or with one or more other network nodes. The processing circuitry is configured to enable the core network node to perform one or more of the described core network node functionalities. The processing circuitry may comprise at least one processor and at least one memory, the memory storing instructions which, upon being executed by the processor, enable the core network node to perform one or more of the described core network node functionalities.

[0022] According to another aspect, some embodiments include a computer program product. The computer program product comprises computer-readable instructions stored in a non-transitory computer-readable storage medium of the computer program product. When the instructions are executed by processing circuitry (e.g., at least one processor) of a core network node, they enable the core network node to perform one or more of the described core network node functionalities.

[0023] According to another aspect, some embodiments include a method performed by a wireless device. The method generally comprises sending an uplink message to a core network node, the uplink message comprising a payload container to be forwarded toward a destination network node, and receiving a downlink message from the core network node, the downlink message comprising an information element indicating that the payload container was not forwarded toward the destination network node.

[0024] The information element indicating that the payload container was not forwarded toward the destination network node may comprise a value indicating congestion, a value indicating that the payload container was not forwarded toward the destination network node, a value indicating that service restriction for the wireless device is active, or a value indicating that the payload container was not forwarded toward the destination network node because service restriction for the wireless device is active.

[0025] The downlink message may comprise, or further comprise, a back-off timer value. The back-off timer value may indicate to the wireless device for how long the wireless device should refrain from transmitting further uplink messages (e.g., further uplink messages comprising payload container to be forwarded toward a destination network node). The downlink message may comprise, or further comprise, the payload container.

[0026] The uplink message may be an uplink NAS transport message. The downlink message may be a downlink NAS transport message.

[0027] The core network node may be a network node implementing an AMF.

[0028] According to another aspect, some embodiments include a wireless device adapted, configured, enabled, or otherwise operable, to perform one or more of the described wireless device functionalities (e.g. actions, operations, steps, etc.).

[0029] In some embodiments, the wireless device may comprise one or more transceivers and processing circuitry operatively connected to the one or more transceivers. The one or more transceivers are configured to enable the wireless device to communicate with one or more radio network nodes over a radio interface. The processing circuitry is configured to enable the wireless device to perform one or more of the described wireless device functionalities. In some embodiments, the processing circuitry may comprise at least one processor and at least one memory, the memory storing instructions which, upon being executed by the processor, enable the wireless device to perform one or more of the described wireless device functionalities.

[0030] According to another aspect, some embodiments include a computer program product. The computer program product comprises computer-readable instructions stored in a non-transitory computer-readable storage medium of the computer program product. When the instructions are executed by processing circuitry (e.g., at least one processor) of a wireless device, they enable the wireless device to perform one or more of the described wireless device functionalities.

[0031] This summary is not an extensive overview of all contemplated embodiments, and is not intended to identify key or critical aspects or features of any embodiments or to delineate any embodiments. Other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments with the figures.

BRIEF DESCRIPTION OF THE FIGURES

[0032] Exemplary embodiments will be described in more detail referring to the following figures, in which:

[0033] Figure 1 is a simplified schematic diagram of the Non-Access Stratum (NAS) protocol stack according the Evolved Packet Core (EPC) architecture.

[0034] Figure 2 is a simplified schematic diagram of the Non-Access Stratum (NAS) protocol stack according the 5G Core (5GC) architecture.

[0035] Figure 3 is a schematic diagram of an example wireless communication network according to some embodiments.

[0036] Figure 4 is a schematic diagram of a portion of an example wireless communication network showing example signaling according to some embodiments.

[0037] Figure 5 is a schematic diagram of a portion of an example wireless communication network showing example core network nodes and related interfaces according to the 5GC architecture.

[0038] Figure 6 is a signaling and operating diagram according to some embodiments.

[0039] Figure 7 is a flow chart of operations of a wireless device according to some embodiments.

[0040] Figure 8 is a flow chart of operations of a core network node according to some embodiments.

[0041] Figure 9 is a block diagram of a wireless device according to some embodiments.

[0042] Figure 10 is a block diagram of a core network node according to some embodiments.

[0043] Figure 11 is another block diagram of a core network node according to some embodiments. DETAILED DESCRIPTION

[0044] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description, given the accompanying figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not addressed herein. These concepts and applications fall within the scope of the description.

[0045] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, can implement appropriate functionality without undue experimentation.

[0046] Referring now to Figure 3, an example of a wireless communication network 100 in which some embodiments may be deployed is depicted. The wireless communication network 100 generally enables wireless devices 110 to communicate with one or more external networks 400 via a radio access network 200 (also referred to as RAN) and a core network 300 (also referred to as CN).

[0047] The radio access network 200 generally comprises a plurality of radio network nodes 210 (only two are shown for clarity) which are responsible for providing radio access, over a radio interface, to wireless devices 110 (only two are shown for clarity) via one or more cells 205. Each cell 205 generally defines a geographical area associated to, and served by, a radio network node 210 where radio coverage is provided by the radio network node 210. Notably, one radio network node 210 may serve more than one cell 205, each of these cells possibly covering different geographical areas.

[0048] The core network 300, which connects the radio access network 200 to one or more external networks 400, generally comprises various core network nodes 310. Though generically referred to as core network nodes 310, different core network nodes 310 may implement or host different core network entities, these different core network entities being responsible for providing one or more core network functions. Examples of core network functions include, but are not limited to, access management, address allocation, connectivity management, lawful interception, mobility management, packet marking, packet inspection, policy control, session management, etc. For simplicity, a core network node 310 implementing a specific core network entity (e.g., a core network node 310 implementing an Access and Mobility Management Function (AMF) as per 3GPP TS 23.501) may be referred to by its specific name (e.g., an AMF 310). [0049] Turning now to Figure 4, additional details of the radio interface between a wireless device 110 and a radio network node 210 are shown. As illustrated, the radio interface generally enables the wireless device 110 and the radio network node 210 to exchange signals and messages in both a downlink direction, that is from the radio network node 210 to the wireless device 110, and in an uplink direction, that is from the wireless device 110 to the radio network node 210.

[0050] The radio interface between the wireless device 110 and the radio network node 210 typically enables the wireless device 110 to access various applications or services provided by one or more servers 410 (also referred to as application server or host computer) located in the external network(s) 400. The connectivity between the wireless device 110 and the server 410, enabled at least in part by the radio interface between the wireless device 110 and the radio network node 210, may be described as an over-the-top (OTT) or application layer connection. In such cases, the wireless device 110 and the server 410 are configured to exchange data and/or signaling via the OTT connection, using the radio access network 200, the core network 300, and possibly one or more intermediate networks (e.g., a transport network) (not shown). The OTT connection may be transparent in the sense that the participating communication devices or nodes (e.g., the radio network node, one or more core network nodes, etc.) through which the OTT connection passes may be unaware of the actual OTT connection they enable and support. For example, the radio network node 210 may not or need not be informed about the previous handling (e.g., routing) of an incoming downlink communication with data originating from the server 410 to be forwarded or transmitted to the wireless device 110. Similarly, the radio network node 210 may not or need not be aware of the subsequent handling of an outgoing uplink communication originating from the wireless device 110 towards the server 410.

[0051] Referring to Figure 5, some of the main core network entities of the 5GC architecture and their related interfaces are illustrated in relation to a wireless device 110, a radio access network 200, and an external network 400. As illustrated, a core network 300 according to the 5GC network architecture comprises an Access and Mobility Management Function (AMF) connected to the wireless device 110 via the N 1 interface and to the RAN 200 via the N2 interface. The AMF 310 is also connected to a Session Management Function (SMF) 310 via a service-based architecture. The SMF 310 is also connected to the User Plane Function (UPF) via the N4 interface. The UPF is connected to the RAN 200 via the N3 interface and to the external network 400 via the N6 interface. The UPF is part of the user plane while the AMF and SMF are part of the control plane. More details about the functions of the AMF, SMF and UPF can be found in section 6.2 of 3GPP TS 23.501 V16.0.2. [0052] In such a context, when Service Gap Control is active for a Rel-16 UE and the service gap timer is running in the UE and the AMF, the UE is allowed to perform initial registration or mobility update registrations. This also applies to Rel-15 UEs that do not support Service Gap Control and hence do not maintain any service gap control timer. The AMF still maintain service gap timers for those Rel-15 UEs.

[0053] Figure 6 illustrates a high-level signaling and operating diagram according to some embodiments.

[0054] After a successful initial or mobility update registration, a NAS signaling connection is established between a wireless device 110 (also referred to as a UE) and an AMF 310 (action S102). As indicated above, a Service Gap timer (e.g., timer T3547 or another timer used or reused for that purpose) is running in the AMF 310 for the wireless device 110. As such, the wireless device 110 should not originate signaling while the Service Gap timer is running. However, in some embodiments, the established NAS signaling connection between the wireless device 110 and the AMF 310 could be used by the wireless device which does not support Service Gap Control (e.g., a Rel-15 wireless device) or could be misused by a wireless device 110 which supports Service Gap Control (e.g., a Rel-16 wireless device) to send a MO 5GSM message, a MO SMS payload, or a MO FPP message piggybacked in an unacknowledged 5GMM message (UE NAS TRANSPORT message), which is not allowed unless there has been downlink signaling sent on the current NAS signaling connection (action SI 04).

[0055] As the UE NAS TRANSPORT message is terminated in the AMF 310, and as the AMF can determine the payload type in the UE NAS TRANSPORT message (e.g., via the Payload Container Type information element), a rejection of the UE NAS TRANSPORT message is possible. In embodiments where the Service Gap timer is running, the AMF 310 determines that Service Gap Control is active for the wireless device 110 (action SI 06). The AMF 310 also obtains information about the content of the payload container carried by the UE NAS Transport message (action SI 08). Notably, though obtaining the information about the content of the payload container is shown occurring after determining that service restriction for the wireless device 110 is active, it is to be understood that these two operations could occur substantially simultaneously or in the reverse order. As indicated above, the AMF 310 may read or otherwise decode the Payload Container Type information element to obtain information about the content of the payload container. As per section 9.11.3.40 of 3GPP TS 24.501 V16.0.2, the Payload Container Type information element present in the UE NAS Transport message indicates what type of content is present in the payload container. The AMF 310 may obtain additional information about the content of the payload container by reading other information elements such as, but not limited to, the Request Type information element which may indicate, for example, whether the payload container is related to an emergency session.

[0056] Based at least in part on the obtained information about the content of the payload container, the AMF 310 then determines whether to forward the content of the payload container toward the appropriate destination network node or to refrain from forwarding the payload container (action SI 10).

[0057] If the AMF 310 determines to refrain from forwarding the payload container toward the destination network node, the AMF 310 may reject the UL NAS Transport message by sending a DL NAS Transport message back to the wireless device 110 (action S112A). The DL NAS Transport message may comprise an information element indicating that the payload container has not been forwarded toward the destination network node. In some embodiments, this information element may be a cause information element comprising a value indicating, to the wireless device, why the payload container has not been forwarded toward the destination network node. In some embodiments, the value may indicate: 1) congestion, 2) that the payload container was not forwarded toward the destination network node, 3) that Service Gap Control for the wireless device is active, or 4) that the payload container was not forwarded toward the destination network node because Service Gap Control for the wireless device is active. The DL NAS Transport message may also comprise a back-off timer value which may indicate to the wireless device 110 for how long the wireless device 110 should refrain from transmitting further uplink messages. The DL NAS Transport message may also comprise the original payload container.

[0058] The content of the DL NAS Transport message sent to the wireless device 110 by the AMF 310 may vary depending on whether the originating wireless device 110 is a wireless device 110 which does not support Service Gap Control (e.g., a Rel-15 wireless device) or is a wireless device 110 which supports Service Gap Control (e.g., a Rel-16 wireless device). For instance, if the originating wireless device 110 does not support Service Gap Control, the AMF 310 may send a DL NAS Transport message in which the cause information element (referred to as 5GMM cause in section 8.2.11 of 3GPP TS 24.501 V16.0.2) indicates, e.g.,“Congestion” or“Payload was not forwarded”, and in which the back-off timer value indicates the remaining value of the Service Gap timer running at the AMF 310. If the originating wireless device 110 does support Service Gap Control, the AMF 310 may send a DL NAS Transport message in which the cause information element indicates, e.g.,“Service Gap Control” or“Payload was not forwarded due to Service Gap Control” and in which the back-off timer value indicates the remaining value of the Service Gap timer running at the AMF 310. Understandably, the exact label of the cause encoded in the cause information element may vary. Notably, the AMF 310 can learn whether the wireless device 110 supports the Service Gap Control during the registration procedure (see section 4.2.2.2 of 3GPP TS 23.502 V16.0.2).

[0059] If the AMF 310 otherwise determines to forward the payload container toward the destination network node, the AMF 310 forwards the payload container toward the destination network node using the appropriate message(s) and interface(s) (action SI 12B).

[0060] Understandably, different payload container may be destined to different destination network node. For example, if the payload container carries a N1 SM information payload, the destination network node may be an SMF 310 as shown in Figure 6. If the payload container carries a Short Message Service message, that is an SMS, the destination network node may be a Short Message Service Function (SMSF) (not shown). If the payload container carries an UTE Positioning Protocol (UPP) message, then the destination network node may be a Gateway Mobile Uocation Centre (GMUC) (not shown).

[0061] Figure 7 is a flow chart illustrating a sequence of operations of the wireless device 110 according to some embodiments. Optional operations, if any, are indicated by dashed lines.

[0062] As illustrated, the wireless device 110 may initially establish a NAS signaling connection with a core network node 310 (e.g., an AMF) (action S202).

[0063] The wireless device 110 then sends an uplink message (e.g., an UU NAS Transport message) to the core network node 310, the uplink message comprising a payload container to be forwarded toward a destination network node (e.g., an SMF, an SMSF, a GMUC, etc.) (action S204).

[0064] Subsequently, the wireless device 110 receives a downlink message (e.g., a DU NAS Transport message) from the core network node 310 (action S206). The downlink message comprises an information element indicating that the payload container was not forwarded toward the destination network node. As indicated above, in some embodiments, this information element may be a cause information element comprising a value indicating, to the wireless device 110, why the payload container has not been forwarded toward the destination network node. In some embodiments, the value may indicate: 1) congestion, 2) that the payload container was not forwarded toward the destination network node, 3) that Service Gap Control for the wireless device is active, or 4) that the payload container was not forwarded toward the destination network node because Service Gap Control for the wireless device is active. The downlink message may also comprise a back-off timer value . The back-off timer value may indicate to the wireless device 110 for how long the wireless device should refrain from transmitting further uplink messages (e.g., further uplink messages comprising a payload container to be forwarded toward a destination network node). The downlink message may also comprise the original payload container.

[0065] After having received the downlink message, the wireless device 110 may refrain from sending further uplink messages to the core network node (action S208). The wireless device 110 may refrain from sending further uplink messages based, at least in part, on the content of the information element indicating that the payload container was not forwarded toward the destination network node, on the content of the back-off timer value information element, or on both.

[0066] Figure 8 is a flow chart illustrating a sequence of operations of a core network node 310 (e.g., an AMF) according to some embodiments. Optional operations, if any, are indicated by dashed lines.

[0067] As illustrated, the core network node 310 (e.g., an AMF) may initially establish a NAS signaling connection with a wireless device 110 (action S302). Here, it is assumed that a service restriction timer (e.g., a Service Gap timer) associated with the wireless device 110 is running in the core network node 310. Notably, a corresponding service restriction timer may or may not be running at the wireless device 110.

[0068] The core network node 310 then receives an uplink message (e.g., an UL NAS Transport message) from the wireless device 110, the uplink message comprising a payload container to be forwarded toward a destination network node (e.g., an SMF, an SMSF, a GMLC, etc.) (action S304).

[0069] The core network node 310 then determines that service restriction for the wireless device 110 is active (actions S306). In some embodiments, the core network node 310 may determine that service restriction for the wireless device 110 is active by determining that the service restriction timer for the wireless device 110 is running.

[0070] The core network node 310 also obtains information about the content of the payload container carried by the uplink message (action S308). As indicated above, the core network node 310 may read or otherwise decode one or more information elements present in the uplink message to obtain information about the content of the payload container. In embodiments where the uplink message is an UL NAS Transport message, the core network node 310 may read the Payload Container Type information element to obtain information about the content of the payload container. As per section 9.11.3.40 of 3GPP TS 24.501 V16.0.2, the Payload Container Type information element present in the UL NAS Transport message indicates what type of content is present in the payload container. The core network node 310 may obtain additional information about the content of the payload container by reading other information elements such as, but not limited to, the Request Type information element which may indicate, for example, whether the payload container is related to an emergency session.

[0071] Notably, though obtaining the information about the content of the payload container is shown occurring after determining that service restriction for the wireless device 110 is active, it is to be understood that these two operations could occur substantially simultaneously or in the reverse order.

[0072] Regardless, upon determining that service restriction for the wireless device 110 is active, the core network node 310 determines whether to forward the payload container toward the destination network node based, at least in part, on the information about the content of the payload container (action S310).

[0073] Subsequently, if, on the one hand, the core network node 310 determines to refrain from forwarding the payload container toward the destination network nodes, then the core network node 310 rejects the uplink message by sending a downlink message to the wireless device 110, the downlink message comprising an information element indicating that the payload container was not forwarded toward the destination network node (action S312A). As indicated above, in some embodiments, this information element may be a cause information element comprising a value indicating, to the wireless device 110, why the payload container has not been forwarded toward the destination network node. In some embodiments, the value may indicate: 1) congestion, 2) that the payload container was not forwarded toward the destination network node, 3) that Service Gap Control for the wireless device is active, or 4) that the payload container was not forwarded toward the destination network node because Service Gap Control for the wireless device is active. The downlink message may also comprise a back-off timer value which may indicate to the wireless device 110 for how long the wireless device should refrain from transmitting further uplink messages. The downlink message may also comprise the original payload container.

[0074] If, on the other hand, the core network node 310 determines to forward the payload container toward the destination network nodes, then the core network node 310 forwards the payload container toward the destination network node using the appropriate message and interface (action S312B).

[0075] It is to be noted that in the previously described signaling and operating diagram(s) and/or flow chart(s), unless the description clearly indicates a certain relationship (e.g., causal, conditional, temporal, etc.) between two or more actions, the described actions may be performed in a different sequence than the one illustrated. For example, two actions shown performed in succession may be performed substantially concurrently, or even in the reverse order. Hence, the illustrated sequence of actions is only indicative of one particular sequence of actions and does not suggest that this is the only possible sequence. Also, the blocks in dashed lines may be considered optional, at least in some embodiments.

[0076] Some embodiments of a wireless device (WD) 110 will now be described referring to Figure 9. Though the expression“wireless device” is used throughout the description, it is to be understood that the expression is used generically. A wireless device generally refers to a device arranged, capable, configured, and/or operable to communicate wirelessly with one or more radio network nodes or with one or more other wireless devices (e.g., via device-to-device (D2D) communication). In other words, a wireless device is a device arranged, capable, configured, and/or operable to perform wireless communications. A wireless device may be portable (or mobile) or may be stationary or fixed at a certain location. In some embodiments, a wireless device may be configured to transmit and/or receive information without direct human interaction. Such a wireless device may be called a Machine Type Communication (MTC) device or a Machine-to- Machine (M2M) device.

[0077] Different communication standards may use different terminology when referring to or describing a wireless device. For instance, 3GPP uses the terms User Equipment (UE), Mobile Equipment (ME), and Mobile Terminal (MT). 3GPP2 uses the terms Access Terminal (AT) and Mobile Station (MS). IEEE 802.11 (also known as WiFi™) uses the term station (STA). Understandably, the generic expression“wireless device” encompasses these terms.

[0078] Figure 9 is a block diagram of an example of a wireless device 110 according to some embodiments. Wireless device 110 includes processing circuitry 112, one or more transceivers 114, and usually additional analog and digital hardware 116. The wireless device 110 may also comprise additional memory 118 and a power source 120 (e.g., a battery).

[0079] The processing circuitry 112 usually provides overall control of the wireless device 110. Hence, the processing circuitry 112 is generally responsible for the various functions of the wireless device 110, either directly or indirectly via one or more other components of the wireless device (e.g., sending or receiving messages via the transceiver 114). The processing circuitry 112 may include any suitable combination of hardware to enable the wireless device 110 to perform the functions of wireless device 110 described above. [0080] In some embodiments, the processing circuitry 112 may comprise at least one processor 122 and at least one memory 124. Examples of processor 122 include, but are not limited to, a central processing unit (CPU), a graphical processing unit (GPU), and other forms of processing unit. Examples of memory 124 include, but are not limited to, Random Access Memory (RAM) and Read Only Memory (ROM). When processing circuitry 112 comprises memory 124, memory 124 is generally configured to store instructions or codes executable by processor 122, and possibly operational data. Processor 122 is then configured to execute the stored instructions and possibly create, transform, or otherwise manipulate data to enable the wireless device 110 to perform the functions of wireless device 110 described above. Additionally, or alternatively, in some embodiments, the processing circuity 112 may comprise one or more application-specific integrated circuits (ASICs), one or more complex programmable logic device (CPLDs), one or more field-programmable gate arrays (FPGAs), or other forms of application-specific and/or programmable circuitry. When the processing circuitry 112 comprises application-specific and/or programmable circuitry (e.g., ASICs, FPGAs), the wireless device 110 may perform one or more functions of wireless device 110 described above without the need for instructions or codes as the necessary instructions may already be hardwired or preprogrammed into the processing circuitry 112. Understandably, the processing circuitry 112 may comprise a combination of processor(s) 122, memory(ies) 124, and other application-specific and/or programmable circuitry.

[0081] The transceiver 114 facilitates transmitting wireless signals to and receiving wireless signals from radio network node 210 and/or other wireless devices 110. Transceiver 114 typically includes one or more transmitters (Tx) 126, and one or more receivers (Rx) 128, both the transmitter(s) 126 and the receiver(s) 128 connected to one or more antennas 130. Transceiver 114 may also comprise signal processing circuitry 132 configured to process the data received from the processing circuitry 112 for transmission via the transmitter(s) 126 and antenna(s) 130, and to process the wireless signals received via the antenna(s) 130 and receiver(s) 128. Signal processing circuitry 132 may comprise any suitable combination of analog signal processing hardware (e.g., amplifier, filter, etc.) and digital signal processing hardware (e.g., digital signal processor (DSP)).

[0082] When present, additional memory 118 may comprise any form of memory, including volatile and/or non-volatile memory, configured to store instructions and/or data that may be used by the processing circuitry 112 of the wireless device 110. Examples of additional memory 118 include, but are not limited to, mass storage media (e.g., a hard disk), removable storage media (e.g., a Compact Disk (CD), a Digital Video Disk (DVD), a memory card). [0083] Power source 120 may, in some embodiments, be in the form of a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic devices or power cells, may also be used.

[0084] As indicated above, in some embodiments, the wireless device 110 may comprise additional analog and digital hardware 116. In some embodiments, the additional analog and digital hardware 116 may comprise one or more input devices 134 for entry of data into wireless device 110. For example, input devices may include one or more microphones, one or more cameras, a touch screen, one or more sensors, etc. Additional analog and digital hardware 116 may additionally or alternatively comprise one or more output devices 136 for outputting data from the wireless device 110. For example, output devices may include one or more speakers, a screen (which may be a touch screen), a vibrating mechanism, one or more actuators, etc. Additional analog and digital hardware 116 may additional or alternatively comprise one or more interfaces 140 to connect the wireless device 110 to external peripherals. Examples of interfaces include, but are not limited to, an Ethernet port, HDMI port(s), USB port(s), etc.

[0085] Other embodiments of wireless device 110 may include additional components beyond those shown in Figure 9 that may provide certain aspects of the wireless device functionalities, including the functionalities described above and/or any additional functionalities (including any functionality necessary to support the solution described above).

[0086] Embodiments of a core network node 310 will now be described referring to Figures 10 and 11. Though the expression“core network node” is used throughout the description, it is to be understood that the expression is used generically. A core network node generally refers to a network node arranged, capable, configured, and/or operable to implement or host one or more core network entities and communicate with one or more radio network nodes, with one or more other core network nodes, and/or possibly with network nodes or servers in the external network(s) 400 to provide or enable one or more core network functions in the wireless communication network 100. In that sense, and as it will described below, a core network entity can be implemented as a network element on a dedicated network node, as a software instance running on a dedicated network node, or as a virtualized network function (VNF) instantiated on a network node providing a virtualization environment. In other words, a core network node is a network node implementing at least one core network entity (e.g. an AMF, an SFM, a UPF, etc.) responsible for at least one core network function.

[0087] Different core network architectures may use different terminology when referring to the various core network entities that can be deployed. For instance, the 3GPP Evolved Packet Core (EPC) architecture comprises Mobility Management Entity (MME), Serving Gateway (SGW), and Packet Data Network (PDN) Gateway (PGW), while the 3GPP 5G Core (5GC) architecture comprises Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF). A more complete list of the different core network entities can be found in section 3 GPP TS 23.401 V16.2.0 and 23.501 V16.0.2.

[0088] Figure 10 is a block diagram of an example of a core network node 310 according to some embodiments. The example of the core network node shown in Figure 10 may be referred to as a “dedicated” core network node 310 in which the core network entity is implemented as a network element or as a software instance on a dedicated network node. As will be described with reference to Figure 11, a core network node 310 may alternatively be a generic network node (e.g., a server in a datacenter) hosting a virtualized instance of the core network entity.

[0089] Core network node 310 usually includes processing circuitry 312 and communication interface(s) 314. Core network 310 may also include external memory 316.

[0090] Processing circuitry 312 usually provides overall control of the core network node 310. Hence, processing circuitry 312 is generally responsible for the various functions of the core network node 310, either directly or indirectly via one or more other components of the core network node 310 (e.g., sending or receiving messages via the communication interface 314). The processing circuitry 312 may include any suitable combination of hardware to enable the core network node 310 to perform the functions of the core network entity it implements.

[0091] In some embodiments, the processing circuitry 312 may comprise at least one processor 318 and at least one memory 320. Examples of processor 318 include, but are not limited to, a central processing unit (CPU), a graphical processing unit (GPU), and other forms of processing unit. Examples of memory 320 include, but are not limited to, Random Access Memory (RAM) and Read Only Memory (ROM). When processing circuitry 312 comprises memory 320, memory 320 is generally configured to store instructions or codes executable by processor 318, and possibly operational data. Processor 318 is then configured to execute the stored instructions and possibly create, transform, or otherwise manipulate data to enable the core network node 310 to perform the functions of the core network entity it implements. Additionally, or alternatively, in some embodiments, the processing circuity 312 may comprise, or further comprise, one or more application-specific integrated circuits (ASICs), one or more complex programmable logic device (CPFDs), one or more field-programmable gate arrays (FPGAs), or other forms of application- specific and/or programmable circuitry. When the processing circuitry 312 comprises application- specific and/or programmable circuitry (e.g., ASICs, FPGAs), the core network node 310 may perform one or more functions of the core network entity it implements without the need for instructions or codes as the necessary instructions may already be hardwired or preprogrammed into processing circuitry 312. Understandably, processing circuitry 312 may comprise a combination of processor(s) 318, memory(ies) 320, and other application-specific and/or programmable circuitry.

[0092] When present, additional memory 316 may comprise any form of memory, including volatile and/or non-volatile memory, configured to store instructions and/or data that may be used by the processing circuitry 312. Examples of additional memory 316 include, but are not limited to, mass storage media (e.g., a hard disk), removable storage media (e.g., a Compact Disk (CD), a Digital Video Disk (DVD), a memory card).

[0093] The communication interface(s) 314 enable the core network node 310 to send messages to and receive messages from other network nodes (e.g., radio network nodes, other core network nodes, servers, etc.). In that sense, the communication interface 314 generally comprises the necessary hardware and software to process messages received from the processing circuitry 312 to be sent by the core network node 310 into a format appropriate for the underlying transport network and, conversely, to process messages received from other network nodes over the underlying transport network into a format appropriate for the processing circuitry 312. Hence, communication interface 314 may comprise appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate with other network nodes.

[0094] Figure 11 is another block diagram of an example of a core network node 310 according to some embodiments. The example of the core network node shown in Figure 11 may be referred to as a“virtualized” core network node 310 in which the core network entity is implemented as one or more virtual network functions (VNFs) running in virtual machines (VMs) in a virtualization environment provided by the core network node 310.

[0095] Broadly, the virtualized core network node 310 generally comprises a hardware infrastructure 342 configured to provide and enable a virtualization environment 344.

[0096] The hardware infrastructure 342 generally comprises processing circuitry 332, communication interface(s) 334, and possibly additional memory 336.

[0097] Processing circuitry 332 usually provides overall control of the hardware infrastructure 342 of the virtualized core network node 310. Hence, processing circuitry 332 is generally responsible for the various functions of the hardware infrastructure 332 either directly or indirectly via one or more other components of the core network node 310 (e.g., sending or receiving messages via the communication interface 334). The processing circuitry 332 is also responsible for enabling, supporting and managing the virtualization environment 344 in which the various VNFs are instantiated and run. The processing circuitry 332 may include any suitable combination of hardware to enable the hardware infrastructure 332 of the virtualized core network node 310 to perform its functions.

[0098] In some embodiments, the processing circuitry 336 may comprise at least one processor 338 and at least one memory 340. Examples of processor 338 include, but are not limited to, a central processing unit (CPU), a graphical processing unit (GPU), and other forms of processing unit. Examples of memory 340 include, but are not limited to, Random Access Memory (RAM) and Read Only Memory (ROM). When processing circuitry 332 comprises memory 340, memory 340 is generally configured to store instructions or codes executable by processor 338, and possibly operational data. Processor 338 is then configured to execute the stored instructions and possibly create, transform, or otherwise manipulate data to enable the hardware infrastructure 342 of the virtualized core network node 310 to perform its functions. Additionally, or alternatively, in some embodiments, the processing circuity 332 may comprise, or further comprise, one or more application-specific integrated circuits (ASICs), one or more complex programmable logic device (CPLDs), one or more field-programmable gate arrays (FPGAs), or other forms of application- specific and/or programmable circuitry. When the processing circuitry 332 comprises application- specific and/or programmable circuitry (e.g., ASICs, FPGAs), the hardware infrastructure 342 of the virtualized core network node 310 may perform its functions without the need for instructions or codes as the necessary instructions may already be hardwired or preprogrammed into processing circuitry 332. Understandably, processing circuitry 332 may comprise a combination of processor(s) 338, memory(ies) 340, and other application-specific and/or programmable circuitry.

[0099] When present, additional memory 336 may comprise any form of memory, including volatile and/or non-volatile memory, configured to store instructions and/or data that may be used by the processing circuitry 332. Examples of additional memory 336 include, but are not limited to, mass storage media (e.g., a hard disk), removable storage media (e.g., a Compact Disk (CD), a Digital Video Disk (DVD), a memory card).

[0100] The communication interface(s) 334 enable the virtualized core network node 310 to send messages to and receive messages from other network nodes (e.g., radio network nodes, other core network nodes, servers, etc.). In that sense, the communication interface 334 generally comprises the necessary hardware and software to process messages received from the processing circuitry 332 to be sent by the virtualized core network node 310 into a format appropriate for the underlying transport network and, conversely, to process messages received from other network nodes over the underlying transport network into a format appropriate for the processing circuitry 332. Hence, communication interface 334 may comprise appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate with other network nodes.

[0101] The virtualization environment 344 is enabled by instructions or codes stored on memory 340 and/or additional memory 336. The virtualization environment 344 generally comprises a virtualization layer 346 (also referred to as a hypervisor), at least one virtual machine 348, and at least one VNF 350. The virtualization layer 346 presents an abstraction of the hardware resources comprised in the hardware infrastructure 342 to the virtual machines 348 in which the VNFs 350 are instantiated. The specific details of this abstraction will depend on the requirements of the VNFs 350. As illustrated, a single virtualized core network node 310 can instantiate and run multiple VNFs 350, each VNF 350 being an instance of a core network entity (e.g., an AMF).

[0102] Some embodiments may be represented as a non-transitory software product stored in a machine -readable medium (also called a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer-readable program code embodied therein). The machine -readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to one or more of the described embodiments. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described embodiments may also be stored on the machine -readable medium. Software running from the machine-readable medium may interface with circuitry to perform the described tasks.

[0103] References in the specification to“one embodiment,”“an embodiment,”“an example embodiment,” etc., indicate that the embodiment described may include a particular feature or a particular combination of features (e.g., component(s), element(s), integer(s), structure(s), operation(s), and/or step(s)), but every embodiment may not necessarily include the particular feature or the particular combination of features. Such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, or a particular combination of features, is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, or combination of features, in connection with other embodiments whether or not explicitly described.

[0104] As used herein, the singular forms“a,”“an,” and“the” should include the plural forms, unless the context indicates otherwise. It will be further understood that the terms“comprises,” “comprising,”“includes,” and/or“including” when used, specify the presence of the stated feature or features, but do not preclude the presence or addition of one or more other features.

[0105] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms used should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0106] The above-described embodiments are examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the description.

ABBREVIATIONS AND ACRONYMS

[0107] The present description may comprise these abbreviations and/or acronyms:

[0108] 3 GPP Third Generation Partnership Project

[0109] 5GC 5G Core

[0110] 5GMM 5G Mobility Management

[0111] 5GS 5G System

[0112] AMF Access Management Function

[0113] CIoT Cellular Internet of Things

[0114] CN Core Network

[0115] D2D Device-to-Device

[0116] eNB evolved Node B

[0117] EPC Evolved Packet Core

[0118] EPS Evolved Packet System

[0119] E-UTRAN Evolved Universal Terrestrial Radio Access Network

[0120] gNB Next Generation Node B (a Node B supporting NR)

[0121] LTE Long Term Evolution

[0122] M2M Machine-to-Machine [0123] MME Mobility Management Entity

[0124] NAS Non-Access Stratum

[0125] NGC Next Generation Core

[0126] NR New Radio

[0127] PGW Packet Data Network Gateway

[0128] RAN Radio Access Network

[0129] SGW Serving Gateway

[0130] SMF Session Management Function

[0131] SMS Short Message Service

[0132] UE User Equipment

[0133] UPF User Plane Function

[0134] VM Virtual Machine

[0135] VNF Virtualized Network Function

RELATED STANDARD REFERENCES

[0136] The following references may be related to the present description:

[0137] 3GPP TS 23.401 V16.2.0

[0138] 3GPP TS 23.501 V16.0.2

[0139] 3GPP TS 23.502 V16.0.2

[0140] 3 GPP TS 24.501 V16.0.2