Patent Description:
In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or User Equipments (UE), communicate via a Local Area Network such as a Wi-Fi network or a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in <NUM>. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node.

Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (<NUM>) network, have been completed within the 3rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (<NUM>) network also referred to as <NUM> New Radio (NR). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a variant of a 3GPP radio access network wherein the radio network nodes are directly connected to the EPC core network rather than to RNCs used in <NUM> networks. In general, in E-UTRAN/LTE the functions of a <NUM> RNC are distributed between the radio network nodes, e.g. eNodeBs in LTE, and the core network. As such, the RAN of an EPS has an essentially "flat" architecture comprising radio network nodes connected directly to one or more core networks, i.e. they are not connected to RNCs. To compensate for that, the E-UTRAN specification defines a direct interface between the radio network nodes, this interface being denoted the X2 interface.

Multi-antenna techniques may significantly increase the data rates and reliability of a wireless communication system. The performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. Such systems and/or related techniques are commonly referred to as MIMO.

In LTE Release <NUM>, a mechanism was introduced for the UE to be suspended by the network in a suspended state similar to RRC_IDLE but with the difference that the UE stores the Access Stratum (AS) context or RRC context. This makes it possible to reduce the signaling when the UE is becoming active again by resuming the RRC connection, instead of as prior to establish the RRC connection from scratch. Reducing the signaling may have several benefits:.

The Release <NUM> solution is based on that the UE sends a RRC Connection Resume Request (RRCConnectionResumeRequest) message to the network such as a network node in the network and in response receives an RRC Connection Resume (RRCConnectionResume) message from the network. The RRCConnectionResume message is not encrypted but integrity protected.

As part of the standardized work on <NUM> NR in 3GPP it has been decided that NR should support an RRC_INACTIVE state with some similar properties as the suspended state in LTE Release <NUM>. The RRC_INACTIVE has slightly different properties from the late state in that it is a separate RRC state and not part of RRC_IDLE as in LTE. Additionally the CN/RAN connection (NG or N2 interface) is kept for RRC_INACTIVE while it was suspended in LTE. <FIG> shows possible state transitions of a UE in NR. The properties of the states above are as follows:.

<FIG> describes a UE triggered transition from RRC_INACTIVE to RRC_CONNECTED:.

After step <NUM> above, when the gNB decides to reject the Resume Request and keep the UE in RRC_INACTIVE without any reconfiguration, or when the gNB decides to setup a new RRC connection, SRB0 (without security) may be used. When the gNB decides to reconfigure the UE, e.g. with a new DRX cycle or RAN-based Notification Area (RNA) RNA or when the gNB decides to push the UE to RRC_IDLE, Signaling Radio Bearer <NUM> (SRB1) with at least integrity protection shall be used.

NOTE: SRB1 may only be used once the UE Context is retrieved i.e. after step <NUM> in <FIG>.

<FIG> describes the network triggered transition from RRC_INACTIVE to RRC_CONNECTED:.

<FIG> describes the UE triggered RNA update procedure when it moves out of the configured RNA involving context retrieval over Xn:.

Although this has been described for NR, an equivalent procedure has been standardized for LTE from Release <NUM> for inactive UEs.

Document "<CIT> (<CIT>)" may be constructed to disclose a method for operating a terminal device in a connected state with respect to a communication network. The method comprises receiving a first signal from a first radio access node in the communication network indicating that the connected state is to be suspended. The first signal comprises information for use in determining a first key for encrypting data to be sent between the terminal device and the first radio access node or another radio access node in the communication network if the connected state is resumed.

Document <NPL>" may be constructed to disclose procedures performed by a UE for RRC inactive state to RRC connected state transition. During the RRC inactive to RRC connected state transition, the UE is required to identify itself (i.e., identify resume identity as UE ID) along with an anchor gNB where a UE context is stored, code-establishment cause information, as well as to provide a security information for the UE integrity verification.

Document "<NPL>" may be constructed to disclose that the UE transmits a RRC resume request message for resumption of the RRC connection by indicating a resume identity, and a resume cause in the RRC resume request message.

Document "<CIT>" may be constructed to disclose a method for security handling. The method comprises receiving in advance (by a UE), from a network node, new parameter and using the new parameter to generate new security keys, when the UE experiences, for example, radio link failure, or handover failure, or reconfiguration failure or any other radio failure. Further, the method comprises using (by the UE) the new security keys for a resume message from which the network node can determine integrity of the UE's resume message and authenticate the UE by omitting transmission of a complete message.

As a part of developing embodiments herein the inventors identified a problem which first will be discussed.

As described above, in the Resume procedure, both in NR and LTE Release <NUM>, the RRCResumeRequest (first RRC message in the procedure from UE to the network) is sent over SRB0 (without encryption and without integrity protection) and includes a security token calculated based on old security keys i.e. the last keys the UE has used. While the expected response message in the successful cases (either an RRCResume or an RRCRelease in the case of RNA) is encrypted and integrity protected based on new security keys. To discuss a problem, the different parts of the procedures have been divided into Part <NUM>, Part <NUM>, and Part <NUM> below.

The current handling of RRC resume is described in section <NUM>. <NUM> of 3GPP TS <NUM>. Specifically, in section <NUM>. <NUM> it is stated that.

After Part <NUM>, as the UE expects in the successful case a response that is encrypted and integrity protected based on new security keys, it is specified in Part <NUM> that the UE refreshes security keys and starts security before sending RRCResumeRequest (or RRCResumeRequest1). Part <NUM> is basically the transmission of the RRCResumeRequest (or RRCResumeRequest1).

However, Part <NUM> is not required for Part <NUM>. Thus, performing part <NUM> before part <NUM> will unnecessarily delay the transmission of the Resume request, and thereby delay the resumption of the connection. That impacts an important Key Performance Indicator (KPI), the control latency, which is basically the delay to perform the resume procedure i.e. the transition from RRC_INACTIVE to RRC_CONNECTED.

<FIG> schematically shows the resume procedure in view of the time it takes to perform different parts of the procedure:.

The UE then sends the resume request message to the network.

The network such as a network node processes the resume request, secedules the UE and sends a resume command, which takes time T3.

The UE processes the resume command and resumes the connection, which takes time T4.

The current way of handling resume Total time= T1 + T2 + T3 + T4
The invention is defined by the independent claims. Further, embodiments of the invention are defined by the claims. Moreover, examples, embodiments and descriptions, which are not covered by the claims are presented not as embodiments of the invention, but as background art or examples useful for understanding the invention.

An object of embodiments herein is therefore to improve speed of resume procedures in a wireless communications network.

According to an aspect of embodiments herein, the object is achieved by a method performed by a User Equipment, UE, for performing a resume procedure of a connection between the UE and a network node, in a wireless communications network. The resume procedure relates to a transmission of the UE from an inactive state to a connected state.

While the UE is in inactive state, the UE performs security update procedures related to security information to be used in the resume procedure of the connection.

After receiving a resume command from the network node as a response to the resume request, the UE resumes the connection between the UE and the network node. The updated security information is used to protect the signalling between the UE and the network node.

According to a further aspect of embodiments herein, the object is achieved by a User Equipment, UE, for performing a resume procedure of a connection between the UE and a network node, in a wireless communications network. The resume procedure relates to a transmission of the UE from an inactive state to a connected state. The UE is configured to: While the UE is in inactive state, perform security update procedures related to security information to be used in the resume procedure of the connection, e.g. by means of a performing model in the UE, and after receiving a resume command from the network node as a response to the resume request, resume the connection between the UE and the network node, wherein the updated security information is adapted to be used to protect the signalling between the UE and the network node.

An advantage of embodiments herein is that UEs will be resumed faster as the security procedures are performed before the UE requests to initiate a resume procedure.

Example embodiments herein relate to different ways to speed up the RRC resume procedure e.g. including the RNA update, by a UE performing security update procedures, like the update of security keys, without delaying the transmission of the resume request message.

In a first group of embodiments, the security update procedures, derivation of new security keys in target cell, configuration of lower layers to resume ciphering/integrity protection etc.. , are performed after transmitting the RRC resume request, while the UE <NUM> is waiting for the RRC resume message, thereby not adding to the overall time required to resume the connection.

In a second group of embodiments, the security update procedures, derivation of new security keys in target cell, configuration of lower layers to resume ciphering/integrity protection, calculation of the RRC security token like the resume MAC-I, etc., are performed even before the request from upper layers or RRC to initiate a resume procedure, for example upon the suspension of the UE <NUM> and/or upon cell reselection/selection while in RRC_INACTIVE, thereby not adding to the overall time required to resume the connection.

An advantage of embodiments herein is that UEs will be resumed faster as the security procedures are performed either after the transmission of the resume request, i.e. updates are deferred until the resume request message is transmitted and while the UE is waiting for the resume command from the network, as in the first group of embodiments, or before the UE <NUM> requests to initiate a resume procedure, i.e. when the UE <NUM> is suspended the UE <NUM> prepares the security updates assuming it can resume in the same cell and perform updates upon selecting/re-selecting a new cell, as in the second group of embodiments.

<FIG> illustrates the advantages of embodiments herein, for the first group of embodiments, as compared to the current way resume is handled in NR.

The UE <NUM> constructs a resume request, which takes time T1.

The UE <NUM> then sends the resume request message to the network.

The UE <NUM> updates security keys and configures lower layers accordingly, at the same time as the network such as a network node processes <NUM> the resume request, schedules the UE <NUM> and sends a resume command, which takes time T3.

The UE <NUM> processes the resume command and resumes the connection, which takes time T4.

The way of handling the resume process according to embodiments herein is speeded up since it takes only a total time= T1 + T3 + T4, which is shorter in time compared to the resume process of prior art shown in <FIG> which takes T1 + T2 + T3 + T4.

For the second group of embodiments, due to pre-computing the resume MAC-I, the UE <NUM> is prepared to send an RRC Resume Request upon a request from upper layers to resume the connection or upon the request form RRC, in the case of RNA update, without the need to perform security actions, which speed up the overall resume procedure. And, due to the pre-computing of the new security keys, the UE <NUM> is prepared to receive RRC Resume message without the need to perform security actions before or after transmitting the resume request, which will speed up the overall resume procedure.

Embodiments herein relate to wireless communication networks in general. <FIG> is a schematic overview depicting a wireless communications network <NUM>. The wireless communications network <NUM> comprises one or more RANs and one or more CNs. The wireless communications network <NUM> may use a number of different technologies, such as Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, <NUM>, New Radio (NR), Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations. Embodiments herein relate to recent technology trends that are of particular interest in a <NUM> context, however, embodiments are also applicable in further development of the existing wireless communication systems such as e.g. WCDMA and LTE.

In the wireless communication network <NUM>, UEs such as a UE <NUM> operate. The UE <NUM> may be a mobile station, a non-access point (non-AP) STA, a STA, a wireless terminals, and is capable to communicate via one or more Access Networks (AN), e.g. RAN, to one or more core networks (CN). It should be understood by the skilled in the art that "wireless device" is a non-limiting term which means any terminal, wireless communication terminal, user equipment, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station communicating within a cell.

The wireless communications network <NUM> comprises one or more radio network nodes such as a radio network node <NUM> providing radio coverage over a geographical area, a service area <NUM>, which may also be referred to as a beam or a beam group of a first radio access technology (RAT), such as <NUM>, LTE, Wi-Fi or similar. The radio network node <NUM> may be a NG-RAN node, a transmission and reception point e.g. a base station, a radio access network node such as a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B), a gNB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of communicating with a wireless device within the service area served by the network node <NUM> depending e.g. on the first radio access technology and terminology used.

Methods herein may be performed by the UE <NUM>. As an alternative, any Distributed Node (DN) and functionality, e.g. comprised in a cloud <NUM> as shown in <FIG>, may be used for performing or partly performing the methods. The network aspects of embodiments herein may be deployed in a cloud environment.

As mentioned above, two groups of embodiments are provided wherein:
<FIG> shows an example method performed by the UE <NUM> e.g. for performing a resume procedure, also referred to as speeding up the resume procedure, of a connection between the UE <NUM> and a network node <NUM>, e.g. an RRC resume procedure, in the wireless communications network <NUM>. The resume procedure may relate to a transmission of the UE <NUM> from an inactive state to a connected state, e.g. from RRC inactive state to RRC connected state.

According to the first group of embodiments, the UE <NUM> will send the resume request before updating the security information, and while waiting for the response from the network node <NUM>, i.e. the resume command, the UE <NUM> will update the security information.

The method may comprise any of the actions below.

In Action 801a, after transmitting a resume request to the network node <NUM> the UE <NUM> performs security update procedures related to security information to be used in the resume procedure of the connection.

In Action 802a, after receiving a resume command from the network node <NUM> as a response to the resume request, the UE <NUM> resumes the connection between the UE <NUM> and the network node <NUM>. The updated security information is used to protect the signalling between the UE <NUM> and the network node <NUM> in the resumed connection.

In these embodiments, the UE <NUM>, when preparing the resume request message, will also update the security information, but it won't use them until it receives the resume message from the network in response to the request it has sent.

According to the first group of embodiments herein, the resume procedure is handled the following way instead of the way it is shown above according to prior art.

According to an example, the UE <NUM> shall set the contents of RRCResumeRequest or RRCResumeRequest1 message as follows:.

It should be noted that despite the way the standard is written, the embodiments herein may be applied as a UE <NUM> implementation, e.g.as the testing for the fulfilment of the requirement relates to the UE <NUM> being able to decode the RRC resume or RRC Release message upon the transmission of the Resume Request, despite a particular order described in the specifications.

<FIG> shows an example method performed by the UE <NUM> e.g. for performing a resume procedure, also referred to as speeding up the resume procedure, of a connection between the UE <NUM> and a network node <NUM>, e.g. an RRC resume procedure, in the wireless communications network <NUM>. The resume procedure may relate to a transition of the UE <NUM> from an inactive state to a connected state, e.g. from RRC inactive state to RRC connected state.

According to the second group of embodiments, the UE <NUM> will do the security update procedure immediately after being suspended, i.e. after being gone to INACTIVE state, and keep updating it when the UE <NUM> does cell reselection procedures, so that by the time the UE <NUM> starts the resume procedure, (i.e. prepares to send the resume request message, the UE <NUM> already have the correct security information.

The method will first be described in short and may comprise any of the actions below.

While the UE <NUM> is in inactive state, such as e.g. in RRC_INACTIVE state, the UE <NUM> performs 801b security update procedures related to security information to be used in the resume procedure of the connection.

After receiving a resume command from the network node <NUM> as a response to the resume request, the UE <NUM> resumes the connection between the UE <NUM> and the network node <NUM>. The updated security information is used to protect the signalling between the UE <NUM> and the network node <NUM>.

In some embodiments, performing of the security update procedures are initiated upon a suspension of the UE <NUM>.

The security update procedures may be performed upon cell reselection and/or selection, while the UE <NUM> is in inactive state, such as e.g. in RRC_INACTIVE.

The security update procedures may e.g. comprise any one or more out of: Derivation of new security keys, configuration of lower layers to resume ciphering, configuration of lower layers to resume integrity protection, and calculation of RRC security token such as a resume Message Authentication Code, for Integrity MAC-I.

The security update procedures are procedures performed by the UE <NUM> itself, i.e. no communication with the network is required when performing security update procedure.

The sequence diagram of <FIG> depicts an example of the second group of embodiments which first will be briefly described will be followed by a more detailed description and examples.

Action <NUM>. The network node <NUM> sends an RRCRelease message with suspendConfig to the UE <NUM>.

Action <NUM>. The UE <NUM> goes to Inactive state.

Action <NUM>. In inactive state, the UE <NUM> updates security keys and configure lower layers accordingly. The time this takes is comprised in the time referred to as (T2).

Action <NUM>. In inactive state, the UE <NUM> further performs cell re-selection based on idle/inactive mode cell re-selection rules, e.g. the UE <NUM> moves out of the coverage area of the current cell that it was camping on.

Action <NUM>. In inactive state, the UE <NUM> further updates security keys and configures lower layers accordingly. The time this takes is comprised in the time referred to as (T2).

Action <NUM>. When the UE <NUM> is in inactive state, UL data may arrive.

Action <NUM>. A DL data that is destined for the UE <NUM> may arrive at the network, upon which the network node sends a RAN paging message.

Action <NUM>. When the UE <NUM> has received the RAN paging message, it constructs an RRCResumeRequest message. The time this takes is comprised in the time referred to as (T1).

Action <NUM>. The constructed RRCResumeRequest message is sent to the network node <NUM>. The time this takes is comprised in the time referred to as T3.

Action <NUM>. The network node <NUM> processes the Resume Request, schedules the UE <NUM>, and constructs the Resume command that will indicate to the UE to resume the RRC connection. The time this takes is also comprised in the time referred to as T3.

Action <NUM>. The network node <NUM> then sends an RRCResume message to the UE <NUM>. The time this takes is also comprised in the time referred to as T3.

Action <NUM>. The UE <NUM> then processes Resume Command message and resumes the connection. The time this takes is comprised in the time referred to as (T4).

Provided way of handling resume according to embodiments herein: The total time = T1 + T3 + T4. This is since the parts of the process in time T2 is done when the UE <NUM> is in inactive state.

In a first example, upon receiving a suspend message, e.g. RRC Release with suspend configuration including the next hop chaining count - NCC, and entering RRC_INACTIVE, the UE <NUM> may compute the RRC security token (resume MAC-I), to be possibly included in the next RRC Resume Request message. For the computation, the UE <NUM> ,may use the old security keys, i.e. the keys in cell the UE <NUM> was suspended, and e.g. the following parameters associated to the cell the UE <NUM> was suspended:.

In a variant of the first example, the UE <NUM> may update the RRC security token (resume MAC-I) upon cell reselection. The UE <NUM> computes the RRC security token (resume MAC-I) to be possibly included in the next RRC Resume Request message in the newly selected/re-selected cell. For the computation, the UE <NUM> may use the old security keys, i.e. the keys in cell in which the UE <NUM> was suspended, and the following parameters associated to newly selected/re-selected cell:.

By doing the actions described in the first example and variant, the UE <NUM> is prepared to send an RRC Resume Request upon a request from upper layers to resume the connection or upon the request form RRC (in the case of RNA update) without the need to perform security actions, which speed up the overall resume procedure.

In a second example, upon receiving a suspend message, e.g. RRC Release with suspend configuration including the next hop chaining count - NCC, and entering RRC_INACTIVE, the UE <NUM> may pre-perform security updates using as target cell the cell the UE <NUM> was suspended, in addition to existing parameters, not cell dependent. The first update is the KgNB key (KgNB*) using the parameters from the cell the UE <NUM> was suspended, in addition to the current KgNB or the NH, and using the received nextHopChainingCount. Two of these parameters may be assigned as follows:.

Then, a second update is the derivation of KRRCint, KRRCenc, KUPenc, and KUPint from the newly updated KgNB*.

In a variant of the second example, upon cell selection/re-selection while in RRC_INACTIVE, the UE <NUM> may perform security updates using as target cell the newly selected/re-selected cell (in addition to existing parameters, not cell dependent). The first update is the KgNB key (KgNB*) using the parameters from the newly selected/re-selected cell (in addition to the current KgNB or the NH, and using the received nextHopChainingCount). Two of these parameters may be assigned as follows:.

Then, the second update is the derivation of KRRCint, KRRCenc, KUPenc, and KUPint from the newly updated KgNB*.

By doing the actions described in the second example and variant, the UE <NUM> is prepared to receive a RRC Resume message without the need to perform security actions, which speed up the overall resume procedure.

Embodiments herein may be considered as having standard impact or being a UE <NUM>-implementation patent. If that is to be standardized, the following may be an alternative. The embodiments herein show the new additions in different parts to illustrate these are independent parts which may be added together or not.

Below is an example showing on how the second example may be captured in the RRC specifications.

It may be FFS: Whether there needs to be different release causes and actions associated.

If that is to be a UE <NUM> implementation embodiment, the provided actions may still be performed regardless of the way the specifications are written. Notice that the testing of that is done by analyzing whether the UE <NUM> may include the correct resume MAC-I and whether the UE <NUM> may decrypt the response message to a resume request (e.g. resume or release message) and verify the network. Hence, a lower latency in that overall resume procedure is an evidence of the following implementation.

Another possible UE <NUM> implementation relies on the usage of parallel processing e.g. with a parallel circuitry at the UE <NUM> to perform security updates in parallel to the preparation of the transmission of the Resume Request. Then, instead of the serial steps described in the specifications, the preparation of the message and security procedures not necessary for the transmission of the message may be done in parallel so that the transmission of the RRC resume Request is not delayed. For example, for the update of Kgb* and the update security keys based on that, before transmitting the resume request, the parallel processing may be used.

<FIG> a and b shows an example of arrangements in the UE <NUM>.

The UE <NUM> may comprise an input and output interface configured to communicate with each other. The input and output interface may comprise a wireless receiver (not shown) and a wireless transmitter (not shown).

The UE <NUM> may comprise a performing module <NUM> and a resuming module <NUM> to perform the method actions as described herein.

The embodiments herein may be implemented through a respective processor or one or more processors, such as the processor <NUM> of a processing circuitry in the UE <NUM> depicted in <FIG>, together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the UE <NUM>. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the UE <NUM>.

The UE <NUM> may further comprise respective a memory <NUM> comprising one or more memory units. The memory comprises instructions executable by the processor in the UE <NUM>.

The memory is arranged to be used to store instructions, data, configurations, and applications to perform the methods herein when being executed in the UE <NUM>.

In some embodiments, a computer program <NUM> comprises instructions, which when executed by the at least one processor, cause the at least one processor of the UE <NUM> to perform the actions above.

In some embodiments, a respective carrier <NUM> comprises the computer program <NUM>, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

Those skilled in the art will also appreciate that the functional modules in the UE <NUM>, described below may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the UE <NUM>, that when executed by the respective one or more processors such as the processors described above cause the respective at least one processor to perform actions according to any of the actions above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).

When using the word "comprise" or "comprising" it shall be interpreted as non-limiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used.

With reference to <FIG>, in accordance with an embodiment, a communication system includes a telecommunication network <NUM> such as the wireless communications network <NUM>, e.g. an loT network, or a WLAN, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a radio access network, and a core network <NUM>. The access network <NUM> comprises a plurality of base stations 3212a, 3212b, 3212c, such as the network node <NUM>, <NUM>, access nodes, AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network <NUM> over a wired or wireless connection <NUM>. A first user equipment (UE) e.g. the UE <NUM> such as a Non-AP STA <NUM> located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE <NUM> e.g. the wireless device <NUM> such as a Non-AP STA in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a.

The intermediate network <NUM> may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network <NUM>, if any, may be a backbone network or the Internet; in particular, the intermediate network <NUM> may comprise two or more subnetworks (not shown).

The hardware <NUM> may include a communication interface <NUM> for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system <NUM>, as well as a radio interface <NUM> for setting up and maintaining at least a wireless connection <NUM> with a UE <NUM> located in a coverage area (not shown) served by the base station <NUM>.

The wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the applicable RAN effect: data rate, latency, power consumption, and thereby provide benefits such as corresponding effect on the OTT service: e.g. reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime.

The communication system includes a host computer, a base station such as the network node <NUM>, and a UE such as the UE <NUM>, which may be those described with reference to <FIG> and <FIG>. In a first action <NUM> of the method, the host computer provides user data. In an optional subaction <NUM> of the first action <NUM>, the host computer provides the user data by executing a host application. In a second action <NUM>, the host computer initiates a transmission carrying the user data to the UE. In an optional third action <NUM>, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth action <NUM>, the UE executes a client application associated with the host application executed by the host computer.

The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to <FIG> and <FIG>. In a first action <NUM> of the method, the host computer provides user data. In an optional subaction (not shown) the host computer provides the user data by executing a host application. In a second action <NUM>, the host computer initiates a transmission carrying the user data to the UE. In an optional third action <NUM>, the UE receives the user data carried in the transmission.

The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to <FIG> and <FIG>. In an optional first action <NUM> of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second action <NUM>, the UE provides user data. In an optional subaction <NUM> of the second action <NUM>, the UE provides the user data by executing a client application. In a further optional subaction <NUM> of the first action <NUM>, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third subaction <NUM>, transmission of the user data to the host computer. In a fourth action <NUM> of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Claim 1:
A method performed by a User Equipment, UE, (<NUM>) for performing a resume procedure of a connection between the UE (<NUM>) and a network node (<NUM>), in a wireless communications network (<NUM>), where the resume procedure relates to a transition of the UE (<NUM>) from an inactive state to a connected state, the method comprising:
while the UE (<NUM>) is in inactive state, performing (801b) security update procedures related to security information to be used in the resume procedure of the connection, wherein the security update procedures comprise calculation of a Radio Resource Control, RRC, security token using old security keys associated to a cell in which the UE was suspended; and
after receiving a resume command from the network node (<NUM>) as a response to a resume request, resuming (802b) the connection between the UE (<NUM>) and the network node (<NUM>), wherein the updated security information is used to protect signalling between the UE (<NUM>) and the network node (<NUM>).