Method and system for handling service request procedure in communication network

The present disclosure relates to a communication method and system for converging a 5th-Generation (5G) communication system for supporting higher data rates beyond a 4th-Generation (4G) system with a technology for Internet of Things (IoT). The present disclosure may be applied to intelligent services based on the 5G communication technology and the IoT-related technology, such as smart home, smart building, smart city, smart car, connected car, health care, digital education, smart retail, security and safety services. The method includes configuring, by a User Equipment (UE) (100), a Protocol Data Unit (PDU) session type as an always-ON type or a normal PDU type. Further, the method includes sending, by the UE (100), a PDU session establishment request message including the PDU session type to be the always-ON type or the normal PDU type to a network (200) during an initial PDU session establishment procedure.

TECHNICAL FIELD

The present disclosure relates to a wireless communication system, and more particularly related to a method and system for handling a service request procedure in the wireless communication system.

BACKGROUND ART

Current 3rd Generation Partnership Project (3GPP) agreement states that a User Equipment (UE)100can support only one service request procedure at a time. This causes an impact when multiple accesses (3GPP access and Non-3GPP access) are involved in the UE100. Consider an example scenario when a service request procedure is on-going over the 3GPP. At the same time, other access (i.e., Non-3GPP) has data/signaling request to be sent to a network, the UE100has to wait to trigger service request over the Non-3GPP until the service request procedure is completed over the 3GPP access which can lead to a significant delay varying between 10 sec to ˜2 min.

There are a lot of existing scenarios which are not been handled properly if the service request procedure is not allowed on the access due to on-going service request procedure on another access. Consider an ideal time for the completion of the service request procedure say is 10 seconds (similar to T3417) considering the message exchanges between the UE100and the network entities (including the communication within the network entities) for all existing scenarios.

In an existing scenario, pre-conditions of UE100includes 3GPP-5GMM-REGISTERED, 5GMM-CONNECTED mode over 3GPP access and Non-3GPP -5GMM-REGISTERED, 5GMM-CONNECTED mode over the non-3GPP access. As shown inFIG.1, the Service Request is initiated over the 3GPP. Though, the UE100is in registered over the Non-3GPP and has data to send (Non-3GPP Protocol Data Unit (PDU's) also would be activated selectively), cannot initiate the service request until the service request procedure over the 3GPP is completed. However, there would be a delay for the non-3GPP PDU until the service request procedure is completed over the 3GPP assuming no failures or re-tries for 3GPP service request.

As shown in theFIG.1, at1, the UE100sends the service request over 3GPP to a 5G Core Network (5GC)200. At2, NON-3GPP PDU has data to send. At3, the user plan/DRB established is established between the UE100and the 5GC200over the 3GPP. At4, the 5GC200sends the service accept message over the 3GPP to the UE100. At5, the UE100sends the service request over the Non-3GPP to the 5GC200.

As shown in theFIG.2, At1, the UE100sends the service request over 3GPP to the 5GC200. At2, NON-3GPP PDU has data to send. At3-At6, the UE100resends the service request over 3GPP to the 5GC200. At7, the user plan/DRB established is established between the UE100and the 5GC200over the 3GPP. At8, the 5GC200sends the service accept message over the 3GPP to the UE100. At9, the UE100sends the service request over Non-3GPP to the network200. At10, UE100waits until TX expires (say 1 min) and at11, the UE100sends the service request over Non-3GPP.

In another existing scenario, as shown in theFIG.2, the service request is initiated for PDU1over the 3GPP. Simultaneously, the UE100has data to send for a PDU2over non-3GPP. However, due to an (any) abnormal case, the service request procedure completion is getting delayed over the 3GPP. Further, due to already on-going service request procedure over the 3GPP, the UE100is unable to send the service request over the Non-3GPP. This scenario leads to a significant delay due to abnormal case in the range of 10 sec to ˜2 min for Non-3GPP PDU2. In general, as per 3GPP specification, timer T3325value is implementation defined with a minimum of 60 seconds. Hence, the delay can be more than 150 seconds depending on the timer value of T3325which is chosen by a particular implementation.

In another existing scenarios, the pre-conditions of the UE100includes 3GPP -5GMM-REGISTERED, 5GMM-CONNECTED mode over 3GPP access and Non-3GPP-5GMM-REGISTERED, 5GMM-CONNECTED mode over the non-3GPP access. The Service Request is initiated for the PDU1over 3GPP. Now, Application/Non-3GPP PDU2mapped to low latency requirements (app which expect low latency) has data to send over 3GPP/Non-3GPP. And, the PDU2has no uplink (UL) established yet. Until on-going Service request procedure over the 3GPP completes, a new Service Request cannot be triggered for PDU2. This scenario leads to not satisfying 5G requirements for low latency services. In successful case where there are no re-tries for the first service request (SR), it will take a maximum of 10 sec before the UE100can request for UL resources for PDU2over 3GPP/Non-3GPP.

In another existing scenario, pre-conditions of UE100includes 3GPP-5GMM-REGISTERED, 5GMM-CONNECTED mode over 3GPP access and Non-3GPP-5GMM-REGISTERED, 5GMM-CONNECTED mode over non-3GPP access. The Service Request is initiated for the PDU1over 3GPP. Concurrently, the network200had downlink (DL) data for other PDU say PDU2(which is established over N3GPP) for which the network200sends a notification to the UE100over 3GPP (cross over of the UE initiated SR and network initiated notification message on the 3GPP access). The UE100cannot initiate response for the notification for Non-3GPP until the on-going Service request procedure over the 3GPP completes. However, this scenario leads to a delay that can vary from 10 Sec to ˜2 min (abnormal case) due to the current agreement.

In another existing scenario, pre-conditions of the UE100includes 3GPP -5GMM-REGISTERED, 5GMM-CONNECTED mode over 3GPP access and Non-3GPP-5GMM-REGISTERED, 5GMM-IDLE mode over non-3GPP access. The Service Request is initiated over 3GPP. Meanwhile, the Non-3GPP Access is in 5GMM-IDLE mode over non-3GPP and has to send Service Request to get into 5GMM-CONNECTED mode as it gained coverage over Non-3GPP access. However, the UE100has to wait to send Service Request over Non-3GPP access until Service request procedure completed over 3GPP access. This scenario can occur more frequently because Non-3GPP coverage can easily be lost and regained based on the Non-3GPP access point. Further, there would be a delay that can range from 10 Sec (assuming no failures or re-tries for the Service Request) to ˜2 min (considering abnormal cases) for Non-3GPP.

In another existing scenario, pre-conditions of UE100includes 3GPP-5GMM-REGISTERED, 5GMM-CONNECTED mode over 3GPP access and Non-3GPP-5GMM-REGISTERED, 5GMM-CONNECTED mode over non-3GPP access. The Service Request is initiated over 3GPP. This is the first attempt of the procedure. Now Non-3GPP needs to send Service Request for mobile originated (MO) data but has to wait until the Service request procedure completes over 3GPP. However, first attempt of Service Request over 3GPP fails. Now, the problem arises should Service Request be triggered for 3GPP or for Non-3GPP. Further, how to handle the situation in which both the accesses have a condition where it has to trigger Service Request. However, there would be a delay of over 10 Sec to ˜2 min to trigger Service Request over either of the access.

In an existing scenario, pre-conditions of UE100includes 3GPP -5GMM-REGISTERED, 5GMM-IDLE over 3GPP and Non-3GPP -5GMM-REGISTERED, 5GMM-CONNECTED over non-3GPP, PDU3& PDU4exists with UP established only for PDU3. A mobility registration update procedure is started. The data is generated for PDU1for 3GPP. Since, the Mobility Registration Update Procedure is on-going, Service Request cannot be sent over 3GPP and is pended until the update procedure is completed. Data is generated for PDU4of Non-3GPP. What should be the behavior at this point? Can the UE100send Service Request over Non-3GPP at this point? After the Mobility Registration Update procedure is successfully completed over 3GPP, then either of the below two cases arise and UE behavior needs to be defined. Case 1: If Service Request is sent over Non-3GPP, then Service Request over 3GPP needs to further wait until Service request procedure over Non-3GPP completes. Case 2: If Service Request is pended, then which Service Request will be processed first 3GPP or Non-3GPP one? However, in either cases, the delay for one Service Request over an access will range from 10 sec to ˜2 min as per the current agreement.

In an existing scenario, pre-conditions of UE100includes 3GPP-5GMM-REGISTERED with PLMN 1, 5GMM-CONNECTED mode over 3GPP access and Non-3GPP-5GMM-REGISTERED with PLMN 2, 5GMM-CONNECTED mode over non-3GPP access. The Service Request is initiated over 3GPP (registered with PLMN 1). Though, the UE100is in registered state over Non-3GPP (with PLMN 2) and has data to send (Non-3GPP PDU's also would be activated selectively), cannot initiate Service Request until Service request procedure over 3GPP is completed. However, there would be a delay for Non-3GPP PDU until Service request procedure is completed over 3GPP assuming no failures or re-tries for 3GPP Service Request. Delay in this scenario is unnecessary as the UE100is registered over different PLMNs.

Thus, it is desired to address the above mentioned disadvantages or other shortcomings or at least provide a useful alternative.

DISCLOSURE OF INVENTION

Technical Problem

The principal object of the embodiments herein is to provide a method and system for handling a service request procedure in a wireless communication system.

Another object of the embodiments herein is to configure, by a UE, a Protocol Data Unit (PDU) session type as an always-ON type.

Another object of the embodiments herein is to send, by the UE, a PDU session establishment request message including the PDU session type to be the always-ON type to a network during an initial PDU session establishment procedure.

Another object of the embodiments herein is to receive, by the network, the PDU session establishment request message including the PDU session type to be the always-ON type from the UE.

Another object of the embodiments herein is to determine, by the network, that the PDU session type as the always-ON type or a normal PDU type based on the PDU session establishment request message.

Another object of the embodiments herein is to initiate, by the UE, one of a service request procedure and a registration request procedure to the network, wherein the one of the service request procedure and the registration request procedure comprises a PDU session identifier with a PDU session type as always-ON type in an uplink data status information element (IE) request.

Another object of the embodiments herein is to activate, by the network, a user plane resource for a particular PDU session for handling service request irrespective of no indication of the PDU session type as the always-ON in an Uplink Status information element (IE) request during one of a service request procedure and a registration request procedure.

Another object of the embodiments herein is to dynamically trigger, by the network, a configuration change corresponding to a PDU session type as an always-ON type to normal PDU type or a normal PDU type to always-ON type using one of a UE generic configuration update procedure and a PDU modification procedure.

Another object of the embodiments herein is to dynamically configure, by the UE, a change corresponding to a PDU session type as an always-ON type to a normal PDU type or a normal PDU type to an always-ON type.

Another object of the embodiments herein is to indicate, by the UE, a PDU session type as one of an always-ON type and a normal type to a network irrespective of a PDU establishment cause in a PDU session establishment request message.

Another object of the embodiments herein is to receive, by the network, the PDU session type as one of the always-ON type and the normal type from the UE.

Another object of the embodiments herein is to determine, by the network, that the

PDU session type as the always-ON type or the normal type based on one of the PDU session establishment request message, a configuration in the network and a subscription in the network.

Another object of the embodiments herein is to define an always on PDU whose user plane resources active whenever a UE is moving from a CM IDLE mode to a CONNECTED mode.

Another object of the embodiments herein is to indicate, by an upper layers (i.e., application layer), whether a PDU is an always-ON PDU or not during an establishment of a PDU session with a network.

Another object of the embodiments herein is to include PDUs of type always-ON in an uplink status IE request to avoid any delay in resource establishment for PDUs, whenever the UE initiates service request or registration request procedure.

Another object of the embodiments herein is to ensure user plane resources for Always-ON PDU when the UE is in the CONNECTED mode.

Another object of the embodiments herein is to determine that PDU to be the always-ON PDU or not in a negotiation between the UE and the network during initial PDU session establishment procedure.

Another object of the embodiments herein is to trigger a configuration change dynamically using procedures (e.g., UE generic configuration update procedures, PDU modification procedures, or the like), if the network decides to change the PDU preference type from an always-ON to normal or vice-versa.

Solution to Problem

Accordingly, the embodiments herein provides a method for handling a service request procedure in a wireless communication system. The method includes configuring, by a User Equipment (UE), a Protocol Data Unit (PDU) session type as an always-ON type or normal PDU type. Further, the method includes sending, by the UE, a PDU session establishment request message to activate the PDU session including the PDU session type to be the always-ON type or the normal PDU type to a network during an initial PDU session establishment procedure. i.e. UE sends Always-on PDU session requested IE as part of PDU SESSION ESTABLISHMENT REQUEST with values either Always-on PDU session requested (indicating UE requests for PDU session type as always-ON type) or Always-on PDU session not requested (indicating UE requests for PDU session type as normal PDU type). Further the terms normal PDU type and not Always-on PDU session are used interchangeably. Further, the method includes receiving, by the network, the PDU session establishment request message including the PDU session type to be the always-ON type or the normal PDU type from the UE. Further, the method includes establishing, by the network, a PDU session with the PDU session type as the always-ON type or the normal PDU type based on the PDU session establishment request message or subscription parameter stored for the PDU session in the network or local configuration information.

In an embodiment, the UE configures the PDU session type as the always-ON type based on one of a configuration in the UE including Universal Integrated Circuit Card (UICC), an indication from upper layers to the NAS layer and a UE Route Selection Policy (URSP) command from the network.

In an embodiment, the network configures the PDU session to be the always-ON type or normal PDU type in a PDU session establishment response message (i.e. for example PDU SESSION ESTABLISHMENT ACCEPT as part of Always-on PDU session indication IE with values Always-on PDU session required or Always-on PDU session not allowed) based on one of a configuration in the network, a subscription in the network and indication of the PDU session type as the always-ON type or normal PDU type from the UE during the PDU session establishment procedure.

In an embodiment, the one of the service request procedure and the registration request procedure comprises the PDU session identifier with the PDU session type as the always-ON type in the uplink data status IE request, even if the user-plane resource for the PDU sessions is not established.

In an embodiment, if the UE has one or more active always-on PDU sessions associated with the access type over which the SERVICE REQUEST message is sent and the user-plane resources for these PDU sessions are not established, the UE shall include the Uplink data status IE in the SERVICE REQUEST message and indicate that the UE has pending user data to be sent for those PDU sessions.

In an embodiment, wherein the UE (100) considers the PDU session type as the normal PDU type irrespective of the UE configuration if the network (200) does not indicate to the UE (100) whether a PDU session is one of the always-ON type or the normal PDU type in the PDU session establishment response from the network (200).

Accordingly, the embodiments herein provides a method for handling a service request procedure in a wireless communication system. The method includes initiating, by a UE, one of a service request procedure and a registration request procedure to a network. The one of the service request procedure and the registration request procedure comprises a PDU session identifier with a PDU session type as always-ON type in an uplink data status information element (IE) request.

In an embodiment, the PDU session identifier with the PDU session type as the always-ON type in the uplink data status IE request indicates setting a bitmap of the PDU session ID in the uplink data status IE.

In an embodiment, the PDU session type as the always-ON type indicates that a user plane resource between the UE and the network is always activated for PDU sessions, when the UE is moving from a CM IDLE mode to a CM-CONNECTED mode.

Accordingly, the embodiments herein provides a method for handling a service request procedure in a wireless communication system. The method includes configuring, by a network, a PDU to be an always-ON. Further, the method includes activating, by the network, a user plane resource for a particular PDU session for handling service request irrespective of no indication of the PDU session type as the always-ON in an Uplink Status information element (IE) request during one of a service request procedure and a registration request procedure.

Accordingly, the embodiments herein provides a method for handling a service request procedure in a wireless communication system. The method includes dynamically triggering, by a network, a configuration change corresponding to a PDU session type as an always-ON type to normal PDU type or a normal PDU type to always-ON type using one of a UE generic configuration update procedure and a network initiated PDU session modification procedure.

Accordingly, the embodiments herein provides a method for handling a service request procedure in a wireless communication system. The method includes dynamically configuring, by User Equipment (UE), a change corresponding to a PDU session type as an always-ON type to a normal PDU type or a normal PDU type to an always-ON type. Further, the method includes indicating, by the UE, a PDU session type as one of an always-ON type and a normal type to a network irrespective of a PDU establishment cause in a PDU session establishment request message. Further, the method includes receiving, by the network, the PDU session type as one of the always-ON type and the normal type from the UE. Further, the method includes determining, by the network, that the PDU session type is as the always-ON type or the normal type based on one of the PDU session establishment request message, a configuration in the network and a subscription in the network.

In an embodiment, the PDU establishment cause indicates at least one of a handover scenario, an emergency scenario, and a normal scenario.

In an embodiment, the PDU session type as the always-ON type is maintained at the UE and the network which can be used during intersystem change between 5G and legacy radio access technologies like 4G.

Accordingly, the embodiments herein provides a wireless communication system for handling a service request procedure. The system includes a UE configuring a Protocol Data Unit (PDU) session type as an always-ON type or the normal PDU type and sending a PDU session establishment request message including the PDU session type to be the always-ON type or the normal PDU type to a network during an initial PDU session establishment procedure. The network receives the PDU session establishment request message including the PDU session type to be the always-ON type or the normal PDU type from the UE and establish a PDU session with the PDU session type as the always-ON type or the normal PDU type based on the PDU session establishment request message.

Accordingly, the embodiments herein provides a wireless communication system for handling a service request procedure. The system includes a UE configured to initiate one of a service request procedure and a registration request procedure to the network, wherein the one of the service request procedure and the registration request procedure comprises a PDU session identifier with a PDU session type as always-ON type in an uplink data status information element (IE) request.

Accordingly, the embodiments herein provides a network for handling a service request procedure in a wireless communication system. The network includes a Protocol Data Unit (PDU) session type handler coupled with a memory and a processor. The PDU session type handler configures a PDU to be an always-ON and activates a user plane resource for a particular PDU session for handling service request irrespective of no indication of the PDU session type as the always-ON in an Uplink Status information element (IE) request during one of a service request procedure and a registration request procedure.

Accordingly, the embodiments herein provides a network for handling a service request procedure in a wireless communication system. The network includes a Protocol Data Unit (PDU) session type handler coupled with a memory and a processor. The PDU session type handler dynamically triggers a configuration change corresponding to a PDU session type as an always-ON type to normal PDU type or a normal PDU type to always-ON type using one of a UE generic configuration update procedure and a PDU modification procedure.

Accordingly, the embodiments herein provides a wireless communication system for handling a service request procedure. The system includes a UE dynamically configures a change corresponding to a PDU session type as an always-ON type to a normal PDU type or a normal PDU type to an always-ON type and indicates a PDU session type as one of an always-ON type and a normal type to a network irrespective of a PDU establishment cause in a PDU session establishment request message. The network receives the PDU session type as one of the always-ON type and the normal type from the UE and determines that the PDU session type as the always-ON type or the normal type based on one of the PDU session establishment request message, a configuration in the network and a subscription in the network.

Advantageous Effects of Invention

The present invention provides a method and system for handling a service request procedure efficeintly in a wireless communication system.

Also, the present invention provides a method and system for configuring a Protocol Data Unit (PDU) session type as an always-ON type efficeintly in a wireless communication system.

MODE FOR THE INVENTION

Embodiments herein achieve a method for handling a service request procedure in a wireless communication system. The method includes configuring, by a User Equipment (UE), a Protocol Data Unit (PDU) session type as an always-ON type or a normal PDU type. Further, the method includes sending, by the UE, a PDU session establishment request message including the PDU session type to be the always-ON type or the normal PDU type to a network during an initial PDU session establishment procedure. Further, the method includes receiving, by the network, the PDU session establishment request message including the PDU session type to be the always-ON type or the normal PDU type from the UE. Further, the method includes establishing, by the network, a PDU session with the PDU session type as the always-ON type or the normal PDU type based on the PDU session establishment request message.

The always-ON type corresponds to an always-on PDU session requested. The normal PDU type corresponds to an always-on PDU session not requested.

Always-on PDU session: A PDU session for which user-plane resources have to be activated during every transition from 5GMM-IDLE mode to 5GMM-CONNECTED mode. A UE requests a PDU session to be established as an always-on PDU session based on indication from upper layers (i.e., application layer) and the network decides whether a PDU session is established as an always-on PDU session or not.

Unlike conventional systems and methods, the proposed method can be used to reduce the delay between two triggers of Service Request procedure within a given access. The proposed method can be used to avoid the delay in establishing the user plane resources for the delay sensitive PDU sessions. Let's says first service request message is sent from the UE and meanwhile the NAS layer receives the request to establish the user plane resources for delay sensitive PDU session say PDU session “x”. Now UE is forced to wait till the first service request procedure is completed before the UE can request the user plane resources for PDU session “x” by re triggering the service request procedure. This delay is not acceptable to delay sensitive services like mission critical.

To solve the above described problem, the UE and network first negotiate whether a PDU session is a delay sensitive PDU session and termed it as an always-ON PDU session. Further, in each service request procedure (or the registration request procedure) UE makes a request for user plane resources for the always-ON PDU session also if user plane resources are not available. So that while service request procedure or registration procedure is ongoing, if there is a uplink data to be sent for always-ON PDU session then user plane resources are readily available to the UE to send the uplink data and there is no delay in requesting for the user plane resources while waiting for the first service request procedure to complete. In other words the first service request procedure or registration procedure already carries request to establish user plane resources for the always on PDU session. Thus UE need not initiate a second service request procedure for always-ON PDU session instead it will get the required user plane resources immediately after completion of the first service request procedure or registration procedure.

The proposed method can be used to completely avoid the delay between service request procedures over single access as they are treated as independent procedures. The proposed method can be used to resolve the dependency of multi-access in trigger of Service Request procedure to reduce the delay significantly.

The proposed method can be used to send a single service request including the list of both 3GPP and Non-3GPP PDUs to be activated maintaining single attempt counter. The proposed method can be used to allow the concurrent Service Request Procedure on two different access and maintain the attempt counter per access. This reduces the delay for either accesses to a pre-determined value.

The method can be used to reduce the data plane establishment latency in the wireless communication system. The proposed method can be used to reduce the signaling overhead which is avoided as PDU establishment procedure needs to be performed for all the PDUs if the UE context gets deleted and paging can also be forwarded from MME to AMF so that the UE does not miss any paging due to the current limitation at least for high priority PDUs or emergency cases.

The method can be used to dynamic configuration of the PDU type (i.e., always-on PDU or not) that is provisioned through procedures like UE Generic configuration update, network initiated PDU session modification or any procedure that supports dynamic configuration of UE from the network.

The proposed method can be used to allow the concurrent Service Request Procedures with each session consisting of a new identifier “Service Request Identifier (SRI)” to distinguish between the sessions and maintain attempt counter, relevant timers of the procedure (T3517, T3325) per session independently. This results in reducing the delay between the trigger of Service Request between the 3GPP and Non-3GPP accesses.

In an embodiment, the method can be used to send a single service request including list of both 3GPP and Non-3GPP PDUs to be activated maintaining single attempt counter. This reduces the delay for either accesses to a pre-determined value. In another embodiment, the method can be used to allow a concurrent service request procedure on two different access and maintain the attempt counter per access. This will completely avoid any delay between the accesses. In another embodiment, the method can be used to allow the concurrent service request procedures with each session consisting of an identifier “Service Request Identifier (SRI)” to distinguish between the sessions and maintaining attempt counter, relevant timers of the procedure (T3517, T3325) per session independently.

In an embodiment, the method allowing the 3GPP and N3GPP accesses in an IDLE Mode and the UE gets paging in 3GPP with N3GPP accesses. Further, the UE can be configured to send the service request with allowed list of N3GPP PDUs which can be moved. Meanwhile, the UE tries to move to a CM_CONNECTED state in the N3GPP by sending the Service Request. This Service request shouldn't be containing PDU which was sent in 3GPP Service Request “in allowed List of PDUs”. It can contain list of PDUs which were not sent in Service Request in 3GPP of “in allowed List of PDU” based on the Uplink Data.

In an embodiment, the method allowing the 3GPP access in the CM-CONNECTED state and N3GPP access in the IDLE Mode and the UE obtains the notification for downlink Data for N3GPP with PDU session identification (id). The UE can be configured to send Service Request if the PDU session for which Notification has come is allowed to be moved over 3GPP otherwise UE shall send Notification Response. Meanwhile, if the UE tries to move to CM_CONNECTED state in N3GPP by sending Service Request. This Service request shouldn't be containing PDU for which Notification had come for downlink Data in 3GPP and if it was allowed to be reactivated over 3GPP. Service request can contain N3GPP PDUs based on uplink Data which are not allowed to be activated over 3GPP or for which Notification didn't come in 3GPP.

In an embodiment, the method allows the UE to trigger Service Request when the UL data is pending for at least one PDU. In an embodiment, the method allows the UE to trigger mobility registration update when there is no uplink data pending.

In the proposed methods, the paging can be forwarded from a Mobility Management Entity (MME) to an Authentication management function (AMF) so that the UE does not miss any paging due to the current limitation at least for high priority PDUs or emergency cases. The method can be used to reduce the data plane establishment latency in the 5G network.

In an embodiment, an application processor (AP) or upper layer that provides PDU type (high priority, low latency or delay intolerant, type of application requesting the PDU etc.) to communication processor (CP) or NAS layer when requesting to establish a PDU session with the network by considering such high priority PDU's in which the upper layer informs to NAS as always-on PDU or priority PDU. This information about the always-on PDU is maintained at CP and used to set the uplink data status IE in subsequent service request or registration procedures whenever these procedures are triggered (ex. After RLF, SR initiated due to pending data etc.). AT commands can also be used to indicate to modem or NAS layer about which PDU's are to be considered as always-on PDU.

In an embodiment, when the UE is activating such always-on PDUs then it shall inform the network during the PDU establishment procedure and the network uses the UE indication of always-on PDU to manage the DRB release due to inactivity timer expiry at RAN side. When inactivity timer expired at RAN for always-on PDU then network should not release the DRB which is mapped to that particular always-on PDU when user plane resource is established for more than 1 PDU. When inactivity timer expired at RAN for always-on PDU and there is no other PDU with established user plane resource for that UE then network shall move the UE to RRC inactive state.

In another embodiment, when sending the service request or the registration request message, the UE marks the PDU's for which data is pending using uplink data status IE. While doing so, the UE can adopt any of the below two approaches. Mark All always-on PDUs (with no user plane resources or with no DRB) in the uplink data status IE. Mark all active PDUs (with no user plane resources or with no DRB) in the uplink data status IE. Alternatively when sending the service request or the registration request message, in case the UE has always-on PDU then the UE will indicate to the network that it needs DRB for all the active PDUs. In such a case, the network should establish the user plane resources for all the active PDU's for the UE. Also, if due to any abnormal scenario, connection between UE and network is lost then it is expected that network shall re-establish user plane resources for Always-On PDUs with UE after establishing connection again.

In another embodiment, if UE receives uplink data for new PDU session ID (always-on PDU) while it is waiting for completing ongoing service request procedure then UE can abort the current ongoing service request procedure and proceed with new service request procedure. When sending the service request, UE marks the PDU's for which data is pending using uplink data status IE. While doing so UE can adopt any of the below two approaches. Mark all always-on PDUs (with no user plane resources or with no DRB) in the uplink data status IE. Mark all active PDUs (with no user plane resources or with no DRB) in the uplink data status IE. Alternatively, when sending the service request or the registration request message, in case UE has always-on PDU then UE will indicate to the network that it needs DRB for all the active PDUs. In such a case, network should establish the user plane resources for all the active PDU's for the UE. Furthermore, at UE side, a SR procedure is marked as completed by checking if DRB is established for all the PDU session ID(s) for which user plane radio resources were requested in last sent service request message and are indicated successfully activated in PDU session reactivation result IE. AT commands can also be used to indicate to modem or NAS layer about which PDU's are to be considered as always-on PDU.

In another embodiment, the UE does not immediately request the already requested PDUs in the last service request, where AT commands can also be used to indicate to modem or NAS layer about which PDU's are to be considered as always-on PDU.

The method can be used identify the always-ON PDU session in the wireless communication system. The method can be used to dynamically change the PDU session type (i.e., always-ON type to normal PDU type or a normal PDU type to the always-ON type. The method can be used to handle the PDU movement between two networks (e.g., 4G network to 5G network or 5G network to 4G network).

Referring now to the drawings, and more particularly toFIGS.3through30, there are shown preferred embodiments.

FIG.3is a sequence diagram illustrating various operations for sending a Service Request Response (Accept/Reject) for both 3GPP and Non-3GPP PDUs over a single access, according to embodiments as disclosed herein.

At1, the UE100sends the service request to the network200over the 3GPP (PTI=1). At1a, the first attempts of service request fails over the 3GPP. At2, NON-3GPP PDU has data to send. At3, the UE100sends the service request to the network200over 3GPP including both 3GPP PDU and non-3GPP PDU. At4, the user plan/DRB established for both 3GPP PDU and non-3GPP PDU. At5, the UE100receives the service accept message including PDU session status for both 3GPP PDU and non-3GPP PDU from the network200.

As shown in theFIG.3, the method includes sending the single Service Request including both 3GPP and Non-3GPP PDUs and maintaining single attempt counter. This reduces the delay for either access to the maximum of 10 seconds. Consider a list of scenarios:

Service Request is triggered over the 3GPP in SGMM-CONNECTED mode, optionally including Procedure Transaction Identity (PTI) to uniquely identify the session/procedure,

Non-3GPP PDU in the SGMM-CONNECTED mode has MO data to send,

First attempt of Service Request procedure over the 3GPP fails due to any abnormal scenario,

(a) Next Service Request attempt should include both 3GPP and Non-3GPP PDUs to be activated incrementing the attempt counter by 1. Therefore, reducing the delay to max T3517seconds, (OR)

(b) Next Service Request attempt should include both 3GPP and Non-3GPP PDUs to be activated resetting the attempt counter to 0. Therefore, reducing the delay to max T3517seconds, (OR)

(c) Next Service Request attempt should include both 3GPP and Non-3GPP PDUs to be activated not changing the value of the attempt counter. Therefore, reducing the delay to max T3517seconds.

The network200sends response (Service Accept or Service Reject) to the Service Request sent by the UE100in either of the two ways:

As shown in theFIG.3, Service Request Response (Accept/Reject) for both 3GPP and Non-3GPP PDUs is sent over single access preferably the access which triggered the Service Request, optionally maintaining the same PTI as in the Service Request message if the UE's SR message includes the PTI.

FIG.4is a sequence diagram illustrating the various operations for sending the Service Request Response (Accept/Reject) over both accesses (3GPP, Non-3GPP individually) for their corresponding PDUs, according to embodiments as disclosed herein.

As shown in theFIG.4, at1, the UE100sends the service request to the network200over 3GPP. At1a, the first attempts of service request fails over the 3GPP. At2, NON-3GPP PDU has data to send. At3, the UE100sends the service request over 3GPP including both 3GPP PDU and non-3GPP PDU. At4a, the user plan/DRB is established for 3GPP PDU. At4b, the UE100receives the service accept message including PDU session status for 3GPP PDU. At4c, the user plan/DRB is established for non-3GPP PDU. At4d, the UE100receives the service accept message including PDU session status for NON-3GPP PDU.

In conjunction with theFIG.3, the network200sends response (Service Accept or Service Reject) to the UE100. The Service Request Response (Accept/Reject) is sent, over both accesses (3GPP, Non-3GPP individually), for their corresponding PDUs and optionally maintaining the same PTI if the UE's SR message includes the PTI.

Further, PTI and a new bit (F) represents Final Response bit needs to be added newly in the Service Accept/Reject message IE to indicate if response message is for single access or both accesses:

A. If this field is not set, then the current response is for one of the accesses and the UE needs to wait for the Service Response message for the other access or wait until procedure timer T3517expires to mark the procedure as completed,

B. If this field is set (it means network is sending the response for both 3GPP, Non-3GPP together) and the UE100will mark the process as completed.

A bit in spare octet can be used for the above mentioned purpose. ->Location of bit needs TBD.

Special Cases for the Service Reject: If any one of the below cause codes comes in Service Reject over one access, then it is applicable to the other access automatically.

Cause Code #8—5GS services not allowed,

Cause Code #11—PLMN not allowed,

Cause Code #22—Congestion (Same core network for 3GPP, Non-3GPP), and

Cause Code #xx—N1 mode not allowed (Registered with same PLMN for 3GPP, Non-3GPP).

All the above proposal is applicable for the case when the UE is registered on the same PLMN in 3GPP and N3GPP with the same AMF.

FIG.5is a sequence diagram illustrating the various operations for allowing concurrent Service Request Procedure on two different accesses and maintaining the attempt counter per access, according to embodiments as disclosed herein.

As shown in theFIG.5, At1, the service request procedure is on-going between the UE100and the network200over 3GPP including PTI=1. At2, NON-3GPP PDU has data to send. At3, the service request procedure is triggered to the network200over non-3GPP including PTI=2. At4, the user plan/DRB is established for 3GPP PDU and at5, the user plan/DRB is established for non-3GPP PDU. At6, the UE100receives the service accept message over 3GPP (PTI=1) and At7, the UE100receives the service accept message over non-3GPP (PTI=2).

As shown in theFIG.5, the method includes allowing concurrent Service Request Procedure on two different accesses and maintaining the attempt counter per access. This will not involve any delay between the accesses.

1. Service Request is triggered over 3GPP in SGMM-CONNECTED mode.

2. Non-3GPP PDU in the SGMM-CONNECTED mode has MO data to send.

3. Now, the UE100sends Service Request over Non-3GPP without waiting for the result of on-going Service Request Procedure over 3GPP.

4. Each access can trigger Service Request Procedure without waiting for the other access. Further, maintain independent attempt counters and handle the procedures independently.

With this proposed method, there won't be any kind of dependency and delay between the accesses for data or signaling procedures.

FIG.6is a sequence diagram illustrating the various operations for maintaining the Service Request Attempt counters per access, according to embodiments as disclosed herein. The MSC depicts that how Service Request Attempt counters is maintained per access as shown in theFIG.6.

As shown in theFIG.6, At1, the service request procedure is on-going over 3GPP including PTI=1. At2, NON-3GPP PDU has data to send. At3, the UE100resends service request procedure over 3GPP including PTI=1. At4, the service request procedure is triggered over non-3GPP including PTI=2. At5, the user plan/DRB is established for 3GPP PDU and At6, the user plan/DRB is established for non-3GPP PDU. At7, the UE100receives the service accept message over 3GPP (PTI=1). At8, the UE100receives the service accept message over non-3GPP (PTI=2).

FIG.7is a sequence diagram illustrating the various operations for allowing a concurrent Service Request Procedures with each session, where both (independent) service request sessions is successful, according to embodiments as disclosed herein.

As shown in theFIG.7, At1, the UE100sends the service request for PDU1with SR=1 over the 3GPP to the network200. At2, PDU2has data to send. At3, the UE100sends the service request for PDU2with SR=2 over 3GPP. At4a, the user plan/DRB is established for 3GPP PDU1. At4b, the UE receives the service accept message with SR=1 for PDU1. At5a, the user plan/DRB is established for 3GPP PDU2. At5b, UE receives the service accept message with SR=2 for PDU2. At 6a, the user plan/DRB is established for PDU1. At6b, the user plan/DRB is established for PDU2. At6c, the UE100receives the service accept message including the PDU session status.

As shown in theFIG.7, the method includes allowing concurrent Service Request Procedures with each session consisting of a new identifier “Service Request Identifier (SRI)” to distinguish between the sessions and maintaining attempt counter, relevant timers of the procedure (T3517, T3325) per session independently. This will completely avoid any delay between the requests over the access. This can be termed as “SRI based Service Request” procedure.

In an embodiment, the method includes only two Service Request Sessions. Further, the allowed number of concurrent sessions is implementation dependent.

1. Service Request is triggered over 3GPP in 5GMM-CONNECTED mode for PDU1with SRI=1.

2. Now, consider a case where PDU2over 3GPP has MO data to send or the network200sent a data notification for PDU2over 3GPP.

3. The UE100triggers Service Request Procedure for PDU2with SRI=2. Irrespective of the response for Service Request session of PDU1(SRI=1), procedure will perform independently for PDU2.

4. Further, below three cases (A, B and C) is possible based on the response from the network200. If the network200sends:

Case A: Service Accept for PDU1including the SRI sent by UE100in the request message. Similarly, the UE100receives Service Accept for PDU2.

Alternatively, the network200can send a single Service Accept Message with updated PDU session status and the UE100will process the message clearing SRI context of only those PDUs for which response has been received from the network200. This is a case where both (independent) service request sessions is successful.

In an embodiment, all SRI based context (i.e., attempt counters, timers, SRI value) related to both the sessions will be cleared after the procedures are completed respectively.

Case B: Due to any abnormal case, there is no response for PDU1Service Request. After T3517expiry, the UE100re-sends Service Request for PDU1(SRI=1). Meanwhile, the UE100receives response (accept/reject) for PDU2Service Request. Both sessions act independently. In an embodiment, if Service Accept comes for PDU2then all the context (attempt counters, timers, and SRI value) will be cleared as procedure is successful else the context is maintained until the procedure is concluded. However, for PDU1(SRI=1) context is maintained on the UE side as procedure is not yet completed.

FIG.8is a sequence diagram illustrating the various operations for allowing concurrent Service Request Procedures with each session, where the UE100keeps attempting until the UE100exhausts the maximum service request attempt limit for each session independently, according to embodiments as disclosed herein.

As shown in theFIG.8, At1, the UE100sends the service request for PDU1with SR=1 over 3GPP. At2, PDU2has MO data to send. At3, the UE100sends the service request for PDU2with SR=2 over 3GPP. At4, First attempts of service request for PDU1fails over 3GPP. At5, the UE100resends the service request for PDU1with SR=1 over 3GPP. At6, First attempts of service request for PDU2fails over 3GPP. At7, the UE100re-sends the service request for PDU2with SR=2 over 3GPP. At8, Maximum attempt reaches for PDU1leading to the start of T3325timer, but one attempt left for PDU2. At9, T3325timer is in running state.

As shown in theFIG.8, there is no response for any of the Service Requests leading to T3517timer expiry for all the existing SRI based SR sessions. The UE100keeps attempting until it exhausts the maximum service request attempt limit for each session independently. If there is no response from network with maximum attempts exhausted for any one session, then stop all on-going service request sessions clearing SRI based service request session context and start timer T3325. UE100can attempt Service Request procedure only if:

UE100has MO data to send for the PDU (new PDU) that has not been part of the last service request sessions (This can be identified using Uplink Data Status IE).

It is in response to paging from the network200.

The below table 1 indicates the Handling for different causes of for service reject.

TABLE 1Special Cases for Service Reject#3 (Illegal UE);Permanent Reject Causes:#6 (Illegal ME);When the UE receives this reject cause#7 (EPS services not allowed);for a particular Service Request, then#10 (Implicitly detached);UE should consider that the other SR's#11 (PLMN not allowed); orif any which are ongoing on the same#35 (Requested service optionaccess have received this same causenot authorized in this PLMN);and proceed accordingly.#12 (Tracking area notAny other causes apart from the listedallowed);ones should be treated for that#13 (Roaming not allowed inparticular SR request only and shouldthis tracking area);not affect the other ongoing SR's if any#15 (No suitable cells intracking area);#22 (Congestion);#40 (No EPS bearer contextactivated);Cause Code #8 - 5GS servicesnot allowedCause Code #xx - N1 mode notallowed (Registered with samePLMN for 3GPP, Non-3GPP)

The below table 2 indicates the special cases for service reject.

TABLE 2Abnormal cases on UE sideLower layer failure or release of theWill apply to all ongoing SR's on that accessNAS signaling connection without“Extended wait time” and withoutredirection indication received fromlower layers before the servicerequest procedure is completed (seesub clause 5.6.1.4) or beforeSERVICE REJECT message isreceivedT3417 expiredIf the sendee request attempt counter isgreater than or equal to 5, the UE shall starttimer T3325.Each transaction has its own T3417, SRattempt counter and T3325 when thecorresponding attempt counter becomes 5.SERVICE REJECT received, otherFor this case it seems to be more appropriateEMM cause values than thoseNOT to affect other ongoing SR's if anytreated in sub clause 5.6.1.5, andcases of EMM cause values #22 and#25, if considered as abnormal casesaccording to sub clause 5.6.1.5Tracking area updating procedure isWill effect all the ongoing SR'striggeredSwitch offWill effect all the ongoing SR'sDetach procedure collisionWill effect all the ongoing SR'sTransmission failure of SERVICEWill effect all the ongoing SR'sREQUEST message indication withTAI change from lower layersTransmission failure of SERVICEWill effect all the ongoing SR'sREQUEST message indicationwithout TAI change from lowerlayers

FIG.9andFIG.10are sequence diagrams illustrating various signaling messages communicated between the UE and the 5GC, according to embodiments as disclosed herein.

As shown in theFIG.9, At1, UE100sends the service request for PDU1with SR=1 over 3GPP. At2, the high priority PDU2has MO data to send. At3, the UE100sends a new service request including PDU1and PDU2with SR=2 over 3GPP. At4, the user plan/DRB is established for 3GPP PDU1. At5, UE receives the service accept message with SR=1 for PDU1. This message is discard by UE100as waiting for response from new SR. At6, the user plan/DRB is established for 3GPP PDU2. At7, the UE100receives the service accept message with SR=2 for PDU1and PDU2. This message is accepted by the UE100.

As shown in theFIG.10, At1, the UE100sends the service request for PDU1with SR=1 over 3GPP. At2, the high priority PDU2has MO data to send. At3, the UE100sends a new service request including PDU1and PDU2with SR=2 over 3GPP. At4, the user plan/DRB is established for 3GPP PDU1and at5, the user plan/DRB is established for 3GPP PDU2. At6, the UE receives the service accept message with SR=2 for PDU1and PDU2.

As shown in theFIG.9andFIG.10, the request for user plane resources (DRB) can be made as quickly as possible. Consider a scenario where the UE100had triggered a service request procedure with SRI=1 (Service Request Identifier) for PDU1. There is a request for MO data to be sent for some other PDU (may be a higher priority PDU). In this case, the UE100shall abort the on-going service request procedure and trigger another service request procedure as an entirely new procedure. To achieve above described behavior, the service request identifier (SRI) is used, which can be used to uniquely identify each service request procedure. It has to be included in each of service request procedure messages (Service request or Service Accept or Service Reject message etc.). The SRI uniquely identify a particular transaction of service request procedure. Optionally, the first Service Request procedures messages may not include the SRI. i.e., only from second service request procedure SRI is included in Service request procedure messages.

In order to understand the concept better, consider example: Service Request is triggered for PDU1with SRI=1. Now, consider a case where the PDU2has to send data over 3GPP or network200sent a data notification for PDU2over 3GPP. As per current prior art, the UE100will block the new service request i.e. block new data request on PDU2, because already the SR procedure is ongoing. It is proposed that the UE100will abort the service request procedure with SRI=1 (i.e. ongoing service request procedure) and shall trigger a new service request procedure in one below ways “case A” or “case B”.

Case A. the UE100to trigger Service Request with SRI=2 including both PDU1, PDU2in Uplink Data Status IE. Now, the network200configures the UE100with bearers for PDU1and sends Service Accept with SRI=1 for PDU1.

The UE100shall discard the Service Accept (or Service Reject) with SRI=1 as the UE100has already aborted the Service Request procedure with SRI=1 and waiting for response for service request with SRI=2.

Meanwhile, the network200configures UE100with bearers for PDU2also and sends a Service Accept message including one of the below possible options:

Service Accept or Service Reject message with SRI=2. This shall be accepted by the UE100.

The UE100to trigger Service Request including only PDU2in Uplink Data Status IE with SRI=1 or 2 (implementation dependent, here SRI=2 used as an example) as for UE100it is a new service request.(Where UE only wants User Plane for PDU2)

The Network configures UE with bearers for PDU1which UE has to discard or release the resources immediately treating it is an invalid message. If Service Accept is included, UE will discard the same.5. Now, network configures UE with bearers for PDU2which UE shall accept gracefully proceeding with the procedure. If Service Accept is included with no information about PDU1(which is expected behavior) indicates the end of the new (second) service request procedure. UE shall trigger SR for PDU1if there is any pending MO data for PDU1or data notification is received from network.

The proposed method handles concurrent Service Request for same access also.

As an implementation option, the AMF500may store the value of PDU session re-activation result IE for time “x” (by running a timer). So that if the AMF500receives a new SR message with increased SRI value compared to previous service request message then the AMF500could act only on delta part of uplink data status IE and for the PDU session ID's it has sent the response to the UE100need not re-request the SMF to establish the DRB. i.e., for example first SR procedure (with SRI1) requested PDU1and PDU2. The AMF500establishes PDU1and PDU2(after requesting SMF) and sends service accept with PDU session reactivation result IE to the UE100. Meanwhile, the AMF500receives new Service request message (with SRI2) with PDU1, PDU2and PDU3then the AMF500uses the stored PDU session reactivation result IE to determine the result of PDU1and PDU2and only for PDU3requests SMF to establish the PDU sessions. Then finally the AMF500sends Service Accept by encoding PDU session reactivation result IE with stored value of PDU1and PDU2(from SRI1) and new result of PDU3.

In yet another embodiment, if user plane resources (or DRB) for a given PDU session is already active then the AMF500shall encode PDU session reactivation result of that particular PDU session is successful activation of PDU session, even though the AMF500receives a request from the UE100to establish that particular PDU session.

FIG.11is a sequence diagram illustrating PDU Movement in the CM connected state at 3GPP, according to embodiments as disclosed herein.

As shown in theFIG.11, At1, the UE100is in a CM Idle on N3GPP access mode and 3GPP Access mode. At2, the AMF500sends a paging indicating non-3GPP access to the RAN. At3, the RAN400sends the paging indicating non-3GPP access to the UE100. At4, the UE100sends the Service Request to the AMF. At5, the UE100is in a CM Idle to connected on N3GPP. At6, the AMF500starts the N3GPP PDU activation on the 3GPP. At7, the UE100shall not trigger Service request over N3GPP for PDU which were allowed to be reactivated in 3GPP until the 3GPP service request procedure is over. Further, the UE100can trigger Service Request for PDUs which are not allowed to be activated over 3GPP.

In an embodiment, the 3GPP and N3GPP access is in IDLE Mode and the UE100obtains paging in 3GPP with N3GPP access. The UE100sends Service Request with allowed list of N3GPP PDUs which can be moved. During the time, the UE100tries to move to CM_CONNECTED state in N3GPP by sending the Service Request.

In an embodiment, the Service request should not be containing PDU which was sent in 3GPP Service Request “in allowed List of PDUs”. It can contain list of PDUs which were not sent in Service Request in 3GPP in “in allowed List of PDU” based on Uplink Data.

FIG.12is a sequence diagram illustrating PDU Movement in CM Connected State at the 3GPP, according to embodiments as disclosed herein.

As shown in theFIG.12, at1, the UE100is in CM Idle on N3GPP access and CM CONNECTED on 3GPP access. At2, the AMF500sends the notification indicating non-3GPP access PDU session id to the RAN. At3, the RAN400sends the notification indicating non-3GPP access PDU session id to the UE100. At4, the UE100sends the service request to the AMF. AT5, the UE100is in CM Idle to connected on N3GPP and At6, the AMF500starts N3GPP PDU activation on 3GPP. At7, the UE100shall not trigger Service request over N3GPP for PDU which was allowed to be re-activated in 3GPP and for which notification had come until the 3GPP service request procedure is over. Further, the UE100can trigger Service request for N3GPP PDUs based on uplink data which are not allowed to be activated over 3GPP or for which notification didn't come in the 3GPP.

In an embodiment, the 3GPP access is in the CM-CONNECTED state and N3GPP access is in the IDLE Mode and the UE100obtains the notification for downlink data for N3GPP with PDU session id/access technology. The UE100sends the service request if the PDU session for which notification has come is allowed to be moved over the 3GPP otherwise, the UE100shall send the notification response. During the time, if the UE100tries to move to CM_CONNECTED state in N3GPP by sending the service request.

In an embodiment, the service request shouldn't be containing PDU for which notification had come for downlink data in 3GPP and if the service request was allowed to be reactivated over 3GPP. Alternatively, the service request shouldn't be containing PDU which is allowed to be reactivated over 3GPP.

The service request can contain N3GPP PDUs based on uplink data which are not allowed to be activated over 3GPP or for which Notification didn't come in 3GPP.

FIG.13is a sequence diagram illustrating that the UE100shall trigger service request when the UL data is pending for at least one PDU, according to embodiments as disclosed herein.

The problem scenario includes:

PDU1and PDU2user plane are active (that is DRB is established) on 3GPP access at1,

RLF occurs at2, and

After the recovery, the UE100can either send the service request if the uplink data is pending (Case A below) or send the mobility update when the uplink data is not pending (Case B below).

The below listed two case scenario provides solution:

Case A: The UE100shall trigger the service request when the UL data is pending for at least one PDU with one of the 3 alternative options:

The UE100triggers the service request including PDU1, PDU2(i.e. all the PDU's that were requested to be activated in the last uplink data status of service request) at4a; or

The UE100triggers the service request concurrently for PDU1, PDU2(i.e. all the PDU's that were requested to be activated in the last uplink data status of service request) at4b; or

The UE100triggers service request immediately after gaining service for the emergency PDU (if any) was active before the occurrence of RLF at4c.

FIG.14is a sequence diagram illustrating that the UE100shall trigger mobility registration update when there is no uplink data pending, according to embodiments as disclosed herein.

Case B: the UE100shall trigger Mobility Registration Update when there is no uplink Data Pending with one of the two options:

UE triggers Mobility Registration Update with Emergency PDU in Uplink Data Status IE at4ain theFIG.14, or

UE triggers Mobility Registration Update including all PDUs active in the last Uplink Data status IE at4bin theFIG.14.

FIG.15is an illustration of a PDU session establishment procedure, according to embodiments as disclosed herein.

As shown in theFIG.15, an application processor (AP) initiates PDU session establishment procedure with communication processor (CP)120or NAS by sending PDU to be established indicating if it is an always-on PDU (i.e. higher priority PDU session). And CP120includes the indication of type in PDU establishment request message to the network200. Later this information of PDU and its type is utilized by the network200during inactivity timer expiry to determine if the user plane resources needs to be released or not. If PDU type is always on, then the network200will not release the user plane resources even upon inactivity timer expiry and continues to maintain the UE context or if the PDU type is always on, then the network200shall not run inactivity timer. Due to any RLF reasons or error situations the DRB is released then the network200shall reactivate the always-on PDU session. The AMF500shall inform gNodeB, SMF, UPF and other relevant network elements about the always-on PDU session. So that if the network elements determine that such PDU sessions DRB's are released the network elements can start the DRB activation process.

As shown in theFIG.15, At1, the AP110requests PDU establishment for PDU5, type—normal/Always-ON to the CP120. At2a, the CP120sends PDU establishment request PDU5, type—normal/Always-ON to the network200. At2b, the CP120stores PDU information (i.e., PDU5, type—normal/Always-ON). At3a, the network200stores PDU information (i.e., PDU5, type—normal/Always-ON). At3b, the PDU session establishment procedure is performed between the AP110and the network200.

FIG.16is an illustration of the network200maintaining UE context, according to embodiments as disclosed herein.

In an embodiment inFIG.16, Where the UE100has more than 1 PDUs with user plane resources of which one is an always on PDU type. When the inactivity timer expires for always on PDU, the network200shall not release the user plane resources maintaining the UE context.

FIG.17is an illustration of the network200instructing the UE100in moving to RRC inactive state, according to embodiments as disclosed herein.

In an embodiment inFIG.17, the UE100has only one PDU which is of type Always ON with active user plane resources. When the inactivity timer expires for this always on PDU, the network200shall not release the user plane resources and instruct the UE100to enter to RRC inactive state at1-3. Alternately, if gNode-B is having Always-On PDU session and inactive timer expires, indicating that there was no data transfer for implementation dependent time then gNode-B can release for the physical resources of DRB and move that particular DRB to INACTIVE state, keeping all other DRB's active. i.e., per DRB INACTIVE state movement. Now whenever data is received on the DRB which is moved to INACTIVE it is resumed with physical resource allocation.

FIG.18is an illustration of performing service request procedure, according to embodiments as disclosed herein.

In an embodiment inFIG.18, at1, if any application has data to send, then the UE100shall send service request including that PDU session id (mapped to the requested application) along with either all other active PDUs or all active PDUs of type always-on which don't have user plane resources in the uplink data status IE at2aand at2b. So, that the delay is minimized and satisfying the key requirements of low latency, delay intolerant service PDUs. Alternatively while sending the service request or the registration request message, the UE100has always-on PDU then the UE100will indicate to the network200that the UE100needs DRB for all the active PDUs. In such a case, the network200should establish the user plane resources for all the active PDU's for the UE100. i.e. in general if AP110has indicated always-on PDU session then each time then the UE100triggers the service request procedure and if the DRB is not established for those PDU sessions then the UE100shall include those PDU session ID's in uplink data status IE. Alternatively, in general if the AP110has indicated always-on PDU session then each time the UE100triggers service request procedure irrespective of DRB established for those PDU sessions, the UE100shall include those PDU session ID's in uplink data status IE. Alternative, if the UE100is of type higher priority access or supporting mission critical service or low latency applications then it shall set all the active PDU session ID's as part of uplink data status IE each time the UE100triggers service request procedure. Alternatively, if the UE100is of type higher priority access or supporting mission critical service or low latency applications then the network200shall run long duration INACTIVE timer, or shall not run INACTIVE timer so that DRB's are never released and whenever DRB release happen network elements shall initiate a procedure to re-establish the DRB's. The network200can understand that UE is of higher priority access or supporting mission critical service or low latency application from subscription information or explicit indication from UE or after determination of type of service UE100is requesting (for example if the UE request for mission critical service and hence establishes those PDU sessions).

In an embodiment inFIG.15-FIG.18, the AP110is indicating (PDU) type as normal or always-on for PDU5. This is done only for clear understanding of the solution. Indication of (PDU) type from the AP110is sent only for always-on PDU otherwise it is implicit that they come under normal PDU type. Always-on (or higher priority PDU session) described in this disclosure is a PDU session which are established for the services which need low latency and low connection establishment time (for example mission critical services).

FIG.19is an illustration of requested DRB's of PDU session, according to embodiments as disclosed herein.

At1, the UE100sends the SR1for PDU5to the network200. At2, the high Priority PDU6has MO data to send. At3, the UE100sends the service request2for PDU5,6. At4, the DRB is established for PDU5and at5, the DRB is established for PDU6and service accept for PDU5and6(PDU Reactivation Result: 0 for PDU5and 0 for PDU6).

In an embodiment, the system disclose about service accept received and all the requested DRB's of PDU session ID's of SR-2are activated. SR procedure is marked as completed from UE perspective as the DRB is established for all the PDU session ID(s) for which user plane radio resources were requested in last sent service request message and are also indicated successfully activated in PDU session reactivation result IE in SERVICE ACCEPT message.

FIG.20is an illustration of PDU session reactivation result, according to embodiments as disclosed herein.

As shown in theFIG.20, at1, the UE100sends the SR1for PDU5to the network200. At2, the high Priority PDU6has MO data to send. At3, the UE100sends the service request2for PDU5,6. At4, the DRB is established for PDU5and service accept for PDU5and6(PDU Reactivation Result: 0 for PDU5and 1 for PDU6).

In an embodiment, system disclose about after receiving service accept message with PDU session reactivation result IE indicating one of the requested PDU session ID's DRB of second service request message establishment has failed. The SR procedure is marked as completed from the UE perspective as the UE100received the user plane activation result for all the PDU session ID(s) for which user plane resources had been requested in the last sent SR message that matches with the PDU session reactivation result IE in the service accept message.

FIG.21is an illustration of receiving second service accept message, according to embodiments as disclosed herein.

As shown in theFIG.20, at1, the UE100sends the SR1for PDU5to the network200. At2, the high Priority PDU6has MO data to send. At3, the UE100sends the service request2for PDU5,6. At4, the DRB is established for PDU5. At5, the network200sends the service accept including the PDU5only (PDU Reactivation Result: 0 for PDU5and 0 for PDU6). At6, the DRB is established for PDU6and service accept for PDU5,6(PDU Reactivation Result: 0 for PDU6)

In an embodiment, the system describes about after receiving second service accept message i.e. when the UE100sends second SR and before it reaches the network200, the AMF500might have responded back with service accept for the first SR. The UE100receives the first service accept for SR1in which the PDU session reactivation result IE indicates successful user plane activation for PDU5. From UE perspective, the SR procedure is still not completed (i.e. UE remains in 5GMM-service-request-initiated state) as user plane resources has not yet been activated for all the PDU session ID's requested in the last send SR message (i.e. in this example for PDU6user plane resources have not yet been established). Further the SR procedure is marked as completed from UE perspective when the UE100receives the next service accept message as it includes the PDU session activation result IE for all the user plane resources requested in the last sent SR message (SR2).

In an embodiment inFIG.19-FIG.21, the system describes about where the UE100has initiated service request procedure and there is a uplink data request received for a new PDU (of higher priority application) while the UE100is waiting for completing the service request procedure then the UE100can abort the current on-going service request procedure and proceed with new service request procedure. The UE100sends service request (uplink data status IE set to 5) message to AMF. The UE100is in 5GMM-service-request-initiated state and 5GMM layer receives a request from upper layers to establish DRB for PDU session ID6. The UE100aborts first service request and sends second service request message (restart T3517) with PDU Session ID in uplink data status IE set to 5 and 6. The network200receives new SR message and processes the latest received SR message. The service request procedure is considered completed on UE side when any of the following events occur.

FIG.22is an illustration of completing UE perspective SR procedure, according to embodiments as disclosed herein.

As shown in theFIG.22, at1, the UE100sends the SR for PDU5to the network200. At2, the high Priority PDU6has MO data to send. At3, the UE100sends the service request for PDU5,6. At4, the DRB is established for PDU5. At5, the DRB is established for PDU6and service accept for PDU5,6(PDU Reactivation Result: 0 for PDU6).

In an embodiment, the UE100has initiated service request procedure and there is a uplink data request received

for a new PDU (of higher priority application) while UE100is waiting for completing the service request procedure then UE100can abort the current on-going service request procedure and proceed with new service request procedure. Further, the UE100sends service request (uplink data status IE set to 5) message to the AMF. The

UE100is in 5GMM-service-request-initiated state and 5GMM layer receives a request from upper layers to establish DRB for PDU session ID6. The UE aborts first service request and sends second service request message with PDU session id in uplink data status IE set to 5 and 6. The network200receives new SR message and processes the latest received SR message. At successful completion of service request procedure, the UE100and network200shall trigger a timer T3519(similar to T3319in 3G). Until expiry of this timer, the UE100shall not initiate service request for the PDUs that were requested in the last service request procedure. Even if UE100initiates service request for the PDUs that were requested in the last service request procedure, the network200is expected to ignore the request until T3519expiry.

In an embodiment inFIG.19toFIG.22, if no service accept message is received from the network200and the timer T3517(guarding the SERVICE REQUEST procedure on the UE side) expires then the UE100marks the service request procedure as completed.

In an embodiment inFIG.19-FIG.22, whenever the UE aborts the first service request procedure (SR1) and sends a new service request message (SR2) then it re-starts the timer T3517(guarding the service request procedure on the UE side).

FIG.23is an illustration of MME600not checking for S-TAU indication, according to embodiments as disclosed herein.

In an embodiment inFIG.23, the system describes about MME600not checking for S-TAU indication. When EPC periodic TAU timer expires in the UE100, then the UE100should be allowed to send an indication to the UDM (via AMF) indicating that the UE100is unable to trigger TAU procedure due to the on-going data session over 5G. The UDM700then shall indicate to MME600that the UE100sent an indication which can be treated as semi-TAU (S-TAU) procedure. The MME600can extend TAU timer expiry for the UE100. Once 5G data session is over, the UE100can trigger TAU and update to MME. Like UDM700, there can be any other node or interface that can be used to route TAU to MME. Periodic timer value to be greater for dual registration supported UEs compared to single registration supported UEs.

FIG.24is an illustration of MME600checking for S-TAU indication, according to embodiments as disclosed herein.

In an embodiment inFIG.24, when EPC periodic TAU timer expires in the UE100, then the UE100should be allowed to send an indication to the UDM (via AMF) indicating that the UE is unable to trigger TAU procedure due to the on-going data session over 5G. When MME side periodic timer expires, the MME600checks with the UDM700if the UE100is available in 5G and any data session is active. If the UDM has received indication from the UE100then UDM700can update to MME600and MME600can keep UE context for some time. Like UDM700, there can be any other node or interface that can be used to route TAU to MME.

In an embodiment, there would be high priority PDUs (delay intolerant, low latency, etc.) whose paging will be missed due to the registration in Dual Rx, Single Tx configuration. Consider a case where the UE100is dual registered (Dual Rx, Single Tx) to both 4G, 5G with an on-going data session over 5G (5G Connected mode, 4G Idle mode). Due to which paging will be missed over 4G if the UE100does not tune for the paging occasions over 4G. This is a major concern. Existing method and system resolve this as in the following by the MME600sends paging to the UE100over 4G and sends notification over 5G (as 5G is in connected mode) simultaneously and the MME600sends notification through 5G only if the MME600is unable to reach the UE (and knows that UE supports dual registration). Alternatively, the MME600can send notification over 5G only if the request has come for high priority PDUs instead of sending notification to 5G for every PDU. Further, high priority PDUs are those with requirements like low latency, delay intolerant or emergency PDUs which shall be prioritized. Upon receiving notification over 5G for a 4G PDU, the UE100needs to perform one of the following actions further the UE100to respond to paging over 4G if MT paging is for a high priority PDU; or the UE100to move 4G PDU (to one to which paging has been received or all the high priority PDUs) to 5G (as 5G is in connected mode).

In an embodiment, UE can tune to 4G during paging occasions to listen to paging or to perform TAU. When Periodic TAU timer expires, UE can tune to 4G to send TAU suspending on-going session over 5G. Once TAU procedure is performed, UE enters 4G IDLE state and resumes suspended data session over 5G. If MT paging has come for high priority PDU, then UE can suspend the current on-going session over 5G to respond to paging for the high priority PDU over 4G and perform movement of PDU from 4G to 5G and respond to paging. High priority PDUs are those with requirements like low latency, delay intolerant or emergency PDUs which shall be prioritized. This approach will lead to high battery consumption and degradation in performance over the RAT with on-going data session. Therefore, this is not an effective solution.

In an embodiment, the network200indicates the PDU to be always-on PDU or not in

PDU session establishment response message to the UE100. In the PDU session establishment request, the UE100shall either indicate PDU Type Preference (Always-ON or Normal) or shall not indicate PDU Type Preference to the network200.

In an embodiment, AT commands can also be used to indicate to modem or NAS layer about which PDU's are to be considered as always-on PDU. During PDU establishment procedure, the UE100shall optionally either indicate PDU type preference (always-on or normal) to the network or does not include the PDU type preference to the network200in the request message and the network200shall indicate a PDU to be always-on PDU or not in PDU session establishment response message to the UE100.

In another embodiment, during PDU movement between accesses like 4G to 5G or vice versa, the UE100shall indicate PDU type preference (always-on or Normal) irrespective of PDU establishment cause (handover, emergency, normal etc.) and network200shall indicate the PDU to be always-on PDU or not in response to the UE100. The UE100shall subsequently use the same indication provided by the network200in response above until network indicates otherwise.

In another embodiment, if it is not necessary that the PDU is always-on PDU throughout, so this characteristic/feature should be configurable dynamically. The network200shall base the decision on different factors like the UE100is camped onto home network or visited network, network slice instance, congestion or priority compared with other higher priority users based on subscription in the current registration area etc. This dynamic configuration of the PDU type (always-on PDU or not) shall be provisioned through procedures like UE generic configuration update, PDU modification or any procedure that supports dynamic configuration of UE.

In another embodiment, the PDU and its type (always-on PDU or not) shall be configured statically through SIM and these corresponding SIM fields shall be updated if the network200dynamically configures it. A few alternatives to achieve this through SIM (adding a new EF) is listed below. Add this feature/rule as part of the URSP (UE route selection policy) for each PDU/DNN/S-NSSAI. Optionally include the expected behavior of the UE for that particular PDU/DNN/S-NSSAI in the home network as well as visited network (can be part of new EF or modify the existing EF). Alternatively, the information shall be stored in the non-volatile memory of the UE. Provision as a configuration object inside UE. Add new EF in SIM for each PDU (optionally one for home or visited network each/one per PDU irrespective of camped network). Alternatively add one EF that defines number of PDUs that are considered by the network200as a candidate for always-on PDUs and adds EF for each PDU to indicate the PDU type preference. The network200shall use static/dynamic methods to update the PDU type preference by network.

In another embodiment, the CP120stores the PDU type preference (always-on or normal) as configured by the network200during static/dynamic methods. Based on this, the CP120shall decide if PDU type is always-on or Normal. Also, the CP120decides the PDU type preference based on AT command parameter, device type or based on latency, priority requirements indicated in the AT command or DNN/APN name.

In another embodiment, the negotiation of PDU type preference (always-on or normal) between the UE100and the network200shall be included as a feature supported by the UE during registration procedure and the network shall confirm if this negotiation feature for PDU is supported or not in the registration response message. The network200shall indicate as an independent feature support or as part of the network feature support IE. Only if the network confirms the feature support, the UE100shall set PDU type preference for a PDU during PDU establishment procedure or other similar procedures where PDU type preference can be negotiated.

In another embodiment, the network or operator shall add pre-defined APN/DNN with always-on PDU type preference called “configured APN/DNN/Slice Based (NSSAI) for always-on PDU Sessions”. These “configured APN/DNN/Slice Based (NSSAI)” can be modified by the network using one of the proposed methods. The UE100shall use the same PDU type preference as set in configured APN/DNN/Slice Based (NSSAI) for always-on PDU Session in all subsequent procedures until network indicates otherwise.

In another embodiment, the method can be used to handle the abnormal cases where the network200sends a reject to UE for the service request or PDU Session Establishment procedure or any other procedures where PDU Type preference is negotiated.

After getting reject with a cause during PDU session establishment procedure, any of the following actions are performed.

Option 1: the UE100can immediately re-request PDU session establishment for that DNN/S-NSSAI but not mark as Always ON,

Option 2: the UE100can re-request the PDU session establishment for that DNN/S-NSSAI and mark as Always-ON ONLY after a pre-defined time based on the cause,

Option 3: the UE100will never re-request that PDU session as always on for that DNN/S-NNSAI, and

Option 4: the UE100can re-request PDU session establishment for that DNN/S-NSSAI and mark as always on based on some pre-defined number of times.

After getting Service Reject, based on the reject cause possible options are:

a) The UE100does not include the always on PDU as part of uplink data status IE when sending the next SR unless there is data pending for that PDU at the time of sending SR,

b) The UE100continues to include the always on PDU as part of uplink data status

IE when sending the next SR,

c) operate as mentioned in point (b) above but only for a pre-defined time and after that time has elapsed then continue as mentioned in point (a) above,

d) Operate as mentioned in point (a) until the UE100is power off, USIM removed,

e) The above 4 options (i.e., a to d) can be performed based on the DNN or S-NSSAI or any combination thereof.

In another embodiment, if the UE100receives the different 5G-GUTI in 3GPP access in registration accept message then the network200indicates that N3GPP registration is required in result IE of registration accept or any other way, then the UE100shall do the re- registration for non-3GPP access using new 5G-GUTI through a N3IWF300.

In another embodiment, if the UE100receives the different 5G-GUTI in 3GPP access in registration accept message then the network200indicates that N3GPP registration is required in result IE of registration accept or any other way, and the UE100shall do the re- registration for non-3GPP access by below way. The UE100will use new 5G-GUTI for routing parameters so that the N3WIF selects the new AMF. In registration message, the UE100shall send the old GUTI which was there for N3WIF, so that new AMF fetches the context from old AMF.

In another embodiment, if the UE100receives the different 5G-GUTI in N3GPP access in registration accept message then the UE100and/or the network200indicate that 3GPP Registration is required in result IE of registration accept or any other way (e.g. if network200provides registration accept only for N3GPP), then the UE100shall do the re-registration for 3GPP using new 5G-GUTI through the 3GPP access RAN.

In another embodiment, if the UE100receive the different 5G-GUTI in N3GPP access in registration accept message then the UE100and/or network200indicates that 3GPP registration is required in result IE of registration accept or any other way (e.g. if the network200provides registration accept only for N3GPP), then the UE100shall do the re- registration for 3GPP using 3GPP access RAN400by below way. The UE100will use new 5G-GUTI for routing parameters so that 5G Node B selects the new AMF. In registration message, the UE shall send the old GUTI which was there for 3GPP, so that new AMF fetches the context from old AMF.

FIG.25is an illustration of the network200indicating the PDU to be always-on

PDU or not in PDU session establishment response message to the UE100, according to embodiments as disclosed herein.

In an embodiment, the when UE100initiates PDU session establishment procedure, either optionally shall indicate the PDU type preference as always-on PDU or normal PDU and the network200shall indicate the accepted PDU preference type (always-on or normal) to the UE100in the PDU session establishment accept message.

FIG.26is an illustration of a method for dynamic configuration of the PDU type (i.e., Always-ON PDU or not) to the UE100, according to embodiments as disclosed herein.

During initial PDU session establishment procedure, the network200and the UE100negotiate the PDU preference type for each PDU. Consider a scenario where the network200decides to modify the PDU preference type from always-on to normal due to say subscription issues. This can be achieved by dynamically configuring the PDU preference type using procedures like UE generic configuration update or PDU modification, etc.

As shown in theFIG.26, At1, Initial PDU session establishment procedure PDU5, Type—Always-ON. At2, the network200stores PDU information (i.e., PDU5, type—normal/Always-ON). At3, the CP120stores PDU information (i.e., PDU5, type—normal/Always-ON (Optionally)). At4, the network decides to change the PDU type preference to normal PDU5, type—normal. At5, the UE100performs the configuration update/PDU Modification Procedure PDU5and Type—Normal.

In an embodiment, if the UE100has one or more active PDU sessions which are not accepted by the network200as always-on PDU sessions and no uplink user data pending to be sent for those PDU sessions then, the UE100shall not include those PDU sessions in the Uplink data status IE in the REGISTRATION REQUEST message.

In an embodiment, if the UE100has one or more active PDU sessions which are not accepted by the network200as always-on PDU sessions and no uplink user data pending to be sent for those PDU sessions then, the UE100shall not include those PDU sessions in the Uplink data status IE in the service request message.

If the Always-on PDU session indication IE is included in the PDU session modification command message then,

the value of the IE is set to “Always-on PDU session required”, the UE100shall consider the established PDU session as an always-on PDU session; or

b) The value of the IE is set to “Always-on PDU session not allowed”, the UE100shall not consider the established PDU session as an always-on PDU session.

In an embodiment, the UE shall not consider the modified PDU session as an always-on PDU session if the UE100does not receive the Always-on PDU session indication IE in the PDU session modification command message.

In an embodiment, if the UE100requests to establish the new PDU session as an always-on PDU session, the UE100shall include the Always-on PDU session requested IE and set the value of the IE to “Always-on PDU session requested” in the PDU session establishment request message.

In an embodiment, the AT commands can be used to indicate to modem/NAS layer about which PDU's are to be considered as always-on PDU. When the UE100initiates PDU session establishment procedure, either optionally shall indicate the PDU type preference as always-on PDU or normal PDU and the network200shall indicate the accepted PDU preference type (always-on or normal) to the UE100in PDU session establishment accept message.

FIG.27is a schematic view of a wireless communication system2700for handling the service request procedure, according to embodiments as disclosed herein. In an embodiment, the wireless communication system2700includes the UE100and the network200. The UE100includes an AP110, a CP120, a PDU session type handler130, a communicator140, a memory150and a processor160. The network200includes a PDU session type handler210, a communicator220, a memory230and a processor240.

The processor160is communicated with the AP110, the CP110, the PDU session type handler130, the communicator140, and the memory150. The PDU session type handler130configures the PDU session type as always-ON type. Further, the PDU session type handler130is configured to initiate one of the service request and the registration request procedure to the network200. The one of the service request and the registration request procedure includes the PDU session type as always-ON type in the uplink status information element (IE) request. Further, the PDU session type handler130is configured to handle the service request procedure in the wireless communication system based on the one of the service request and the registration request procedure including the PDU session type as always-ON type in the uplink status IE request.

In an embodiment, the PDU session type as always-ON type indicates that activate user plane resources between the UE100and the network200, when the UE100is moving from the CM IDLE mode to the CONNECTED mode. In an embodiment, the PDU session type as always-ON type in the uplink status IE request avoids the delay in resource establishment for PDUs.

In an embodiment, the PDU session type as always-ON type manages user plane resources when the UE (100) is in the CM_CONNECTED mode.

In an embodiment, the PDU session type handler130is configured to request a PDU session to be established as the always-on PDU session based on indication from the upper layers (e.g. application layer110) and the network200decides whether the PDU session is established as the always-on PDU session.

In an embodiment, the UE (100) configuring a Protocol Data Unit (PDU) session type as an always-ON type and send a PDU session establishment request message including the PDU session type to be the always-ON type to a network (200) during an initial PDU session establishment procedure. The network (200) receives the PDU session establishment request message including the PDU session type to be the always-ON type from the UE (100) and determines that the PDU session type as the always-ON type or a normal PDU type based on the PDU session establishment request message.

In an embodiment, the UE (100) configures the PDU session type as the always-ON type based on one of a configuration in a Universal Integrated Circuit Card (UICC), an indication from upper layers, and attention (AT) commands.

In an embodiment, the PDU session type is determined as the always-ON type or the normal PDU type based on one of a configuration in the network (200), a subscription in the network (200), and indicating to the UE (100) in a PDU session establishment response message.

In an embodiment, the network (200) configures the PDU session to be the always-ON type in a PDU session establishment response message based on one of a configuration in the network (200) and a subscription in the network (200) irrespective of no indication of the PDU session type as the always-ON type from the UE (100) during the PDU session establishment procedure.

In an embodiment, the UE (100) configures the PDU session type as the always-ON type based on the UE configuration irrespective of no indication in the PDU session establishment response from the network (200).

In an embodiment, the UE (100) is configured to initiate one of a service request procedure and a registration request procedure to the network (200), wherein the one of the service request procedure and the registration request procedure comprises a PDU session identifier with a PDU session type as always-ON type in an uplink data status information element (IE) request.

In an embodiment, the PDU session identifier with the PDU session type as the always-ON type in the uplink data status IE request indicates setting a bitmap of the PDU session ID in the uplink data status IE which is the always-ON type.

In an embodiment, the PDU session type as the always-ON type indicates that a user plane resource between the UE (100) and the network (200) is always activated for PDU sessions, when one of the UE (100) is moving from a CM IDLE mode to a CM-CONNECTED mode and the UE (100) is in a CM-CONNECTED mode.

In another embodiment, the UE (100) dynamically configures a change corresponding to a PDU session type as an always-ON type to a normal PDU type or a normal PDU type to an always-ON type and indicates a PDU session type as one of an always-ON type and a normal type to a network (200) irrespective of a PDU establishment cause in a PDU session establishment request message. The network (200) receives the PDU session type as one of the always-ON type and the normal type from the UE (100) and determines that the PDU session type as the always-ON type or the normal type based on one of the PDU session establishment request message, a configuration in the network (200) and a subscription in the network (200).

In an embodiment, the PDU establishment cause indicates at least one of a handover scenario, an emergency scenario, and a normal scenario.

In an embodiment, the PDU session type as the always-ON type is maintained at the UE (100) and the network (200).

In an embodiment, the UE100has one or more active PDU sessions which are not accepted by the network200as always-on PDU sessions and no uplink user data pending to be sent for those PDU sessions then, the PDU session type handler130shall not include those PDU sessions in the uplink data status IE in a registration request message.

In an embodiment, if the UE100has one or more active PDU sessions which are not accepted by the network200as always-on PDU sessions and no uplink user data pending to be sent for those PDU sessions, the PDU session type handler130shall not include those PDU sessions in the uplink data status IE in the service request message.

In an embodiment, the UE100shall not consider the modified PDU session as the always-on PDU session if the PDU session type handler130does not receive the Always-on PDU session indication IE in the PDU session modification command message.

In an embodiment, if the UE100requests to establish a new PDU session as the always-on PDU session, the PDU session type handler130shall include the always-on PDU session requested IE and set the value of the IE to “Always-on PDU session requested” in the PDU session establishment request message.

In an embodiment, the requested PDU session needs to be established as the always-on PDU session, a SMF shall include the always-on PDU session indication IE in the PDU SESSION ESTABLISHMENT ACCEPT message and shall set the value to “Always-on PDU session required”.

Below table 3 indicates the PDU session establishment request message content.

Below table 4 indicates PDU SESSION ESTABLISHMENT ACCEPT message content.

Below table 5 indicates the PDU SESSION MODIFICATION REQUEST message content.

The Always-on PDU session requested information element is coded as shown in table 6.

Table 7 indicates the Always-on PDU session requested information:

In another embodiment, the Always-on PDU session indication information element is coded as shown in table 8. The Always-on PDU session indication is a type 1 information element.

Table 9 indicates the Always-on PDU session indication.

TABLE 9Always-on PDU session indication (APSI) (octet 1)Bit10Always-on PDU session not allowed1Always-on PDU session requiredBits 2, 3 and 4 are spare and shall be coded as zero,

The processor160is configured to execute instructions stored in the memory150and to perform various processes. The communicator140is configured for communicating internally between internal hardware components and with external devices via one or more networks.

In an embodiment, the network (200) includes a PDU session type handler (210) coupled with the memory (230) and the processor (240). The PDU session type handler (210) is configured to receive one of a service request and a registration request procedure from a UE (100). The one of the service request and the registration request procedure includes a Protocol Data Unit (PDU) session identifier and PDU session type as an always-ON PDU type. The PDU session type handler (210) is configured to determine to provide user plane resources for PDUs based on the PDU session identifier. The PDU session type handler (210) is configured to handle the service request procedure in the wireless communication system based on the user plane resources.

In an embodiment, the PDU session type handler (210) configures a PDU to be an always-ON and activates a user plane resource for a particular PDU session for handling service request irrespective of no indication of the PDU session type as the always-ON in an Uplink Status information element (IE) request during one of a service request procedure and a registration request procedure.

In an embodiment, the PDU session type handler (210) dynamically triggers a configuration change corresponding to a PDU session type as an always-ON type to normal PDU type or a normal PDU type to always-ON type using one of a UE generic configuration update procedure and a PDU modification procedure.

In an embodiment, the PDU session type handler (210) is configured to receive one of a service request and a registration request procedure from a User Equipment (UE) (100). The one of the service request and the registration request procedure includes a Protocol Data Unit (PDU) session identifier with a PDU session type as an always-ON

PDU type. The PDU session type handler (210) is configured to determine to provide user plane resources for PDUs based on the PDU session identifier. The PDU session type handler (210) is configured to dynamically trigger the configuration change corresponding to the PDU session type using one of a UE generic configuration update procedure and a PDU modification procedure. The PDU session type handler (210) is configured to handle the service request procedure in the wireless communication system based on the configuration change.

In an embodiment, the PDU session type handler (210) is configured to determine that a PDU session type to be Always-ON PDU type or a normal PDU type in a negotiation between a User Equipment (UE) (100) and the network (200) during an initial PDU session establishment procedure. The PDU session type handler (210) is configured to determine to provide the user plane resources for PDUs. The PDU session type handler (210) is configured to handle the service request procedure in the wireless communication system based on the user plane resources.

The processor240is configured to execute instructions stored in the memory230and to perform various processes. The communicator220is configured for communicating internally between internal hardware components and with external devices via one or more networks.

In an embodiment, the PDU session type handler (130) includes a PDU session type configuration unit used to handle the service request procedure in the wireless communication system. In an embodiment, the PDU session type handler (210) includes a PDU type determining unit, a user plane resource handling unit, a PDU session type handling unit used to handle the service request procedure in the wireless communication system.

Although theFIG.27shows various hardware components of the wireless communication system2700but it is to be understood that other embodiments are not limited thereon. In other embodiments, the wireless communication system2700may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function to handle the service request procedure in the wireless communication system2700.

FIG.28-30are flow diagrams2800-3000illustrating various operations, implemented by the wireless communication system2700, handling the service request procedure, according to embodiments as disclosed herein.

As shown in theFIG.28, at2802, the UE (100) configures the PDU session type as the always-ON type or the normal PDU type. At2804, the UE (100) sends the PDU session establishment request message including the PDU session type to be the always-ON type or the normal PDU type to the network (200) during the initial PDU session establishment procedure. At2806, the network (200) receives the PDU session establishment request message including the PDU session type to be the always-ON type or the normal PDU type from the UE (100). At2808, the network (200) establishes the PDU session with the PDU session type as the always-ON type or the normal PDU type.

As shown in theFIG.29, at2902, the network (200) configures the PDU to be the always-ON. At2904, the network (200) activates the user plane resource for the particular PDU session for handling service request irrespective of no indication of the PDU session type as the always-ON in the Uplink Status IE request during one of a service request procedure and a registration request procedure.

As shown in theFIG.30, At3002, the UE (100) dynamically configures the change corresponding to the PDU session type as an always-ON type to a normal PDU type or a normal PDU type to an always-ON type. At3004, UE (100) indicates the PDU session type as one of an always-ON type and a normal type to a network (200) irrespective of a PDU establishment cause in a PDU session establishment request message. At3006, the network (200) receives the PDU session type as one of the always-ON type and the normal type from the UE (100). At3008, network (200) determines that the PDU session type as the always-ON type or the normal type based on one of the PDU session establishment request message, a configuration in the network (200) and a subscription in the network (200).

The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements.