Method and system for performing network procedures for reduced capability devices in a network

Abstract

A method (900) and a system (108) for supporting Reduced Capability (RedCap) devices in a network (106) is described The method includes receiving, by a primary network function, a message from a Radio Access Network (RAN). The received message indicate that a User Equipment (UE) (104) is a New Radio (NR) RedCap device. The method includes modifying, by the primary network function, a Radio Access Technology (RAT) type associated with the RedCap device from NR RedCap to NR for communication with each of a set of secondary network functions. The method further includes transmitting, by the primary network function, one or more messages comprising the modified RAT type to at least one of the set of secondary network functions during a registration procedure, a session establishment procedure, and a handover procedure.

Description

METHOD AND SYSTEM FOR PERFORMING NETWORK PROCEDURES FOR REDUCED CAPABILITY DEVICES IN A NETWORKRESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to JIO PLATFORMS LIMITED or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of telecommunications. More particularly, the present disclosure relates to method and system for performing network procedures for reduced capability devices in a network.DEFINITION

[0003] The term ‘Access and Mobility Management Function (AMF)’ as used herein, refers to a network function that is responsible for managing access and mobility procedures for User Equipment (UE), including registration, connection management, authentication, security, and mobility management. It also acts as an intermediary between the Radio Access Network (RAN) and other 5G Core functions.

[0004] The term ‘Policy Control Function (PCF)’ refers to a network function responsible for policy management and control. It determines rules for resource allocation, QoS (Quality of Service), and access control based on operator-defined policies.

[0005] The term ‘Session Management Function (SMF)’ refers to a network function in 5G responsible for managing PDU (Protocol Data Unit) sessions, including session establishment, modification, and release. It also handles IP address allocation and interaction with the User Plane Function (UPF).

[0006] The term ‘Unified Data Management (UDM)’ refers to a network function responsible for managing subscriber-related data, such as subscription profiles and authentication information.

[0007] The term ‘User Plane Function (UPF)’ refers to a network function in 5G that handles user data traffic, routing, forwarding, and packet inspection between the RAN and external networks.

[0008] The term ‘Reduced Capability (RedCap) device’ refers to a category of UEs with reduced complexity and capabilities designed to support use cases like loT, industrial automation, or wearables. These devices balance lower data rates and power consumption while meeting specific connectivity requirements.

[0009] The term ‘Radio Access Network (RAN)’ refers to a part of the 5G network that provides wireless connectivity between UEs and the Core Network (CN). It handles functions like radio resource management, handovers, and communication with the A MF.

[0010] The term ‘New Radio (NR)’ refers to a 5G wireless communication standard defined by existing standards, which provides enhanced data rates, lower latency, and higher reliability compared to earlier standards.

[0011] The term ‘Radio Access Technology (RAT)’ refers to a wireless communication technology used by a network to enable connectivity between the UE and the RAN. RAT defines air-interface protocols, modulation schemes, bandwidth capabilities, and overall communication characteristics supported by the UE. Examples of RAT include New Radio (NR) used in 5G systems, Long Term Evolution (LTE) used in 4G systems, NR RedCap, and similar. Different RAT types help the network identify the capability category of the UE and apply appropriate procedures for registration, mobility, and session management.

[0012] The term ‘Protocol Data Unit (PDU) session’ refers to a data session established between the UE and the data network to enable services like Internet access.

[0013] The term ‘Handover’ refers to a procedure of transferring a UE’s connection from one cell or RAN node to another to maintain uninterrupted service.

[0014] The term ‘Path Switch Request’ refers to a message sent by the target RAN node to the AMF during Xn or N2 handover procedures to indicate the path switching of a UE’s connection.

[0015] The term ‘Xn Handover’ refers to a handover procedure used in a 5G network where the UE transitions from one gNodeB (gNB) to another gNB via the Xn interface. This type of handover is intra-5G and allows seamless mobility within the same Public Land Mobile Network (PLMN) or between different PLMNs when both source and target gNBs are connected through the Xn interface.

[0016] The term ‘N2 Handover’ refers to a handover procedure in a 5 G network where the UE transitions between gNBs via the N2 interface, which connects the gNB to the AMF. Unlike Xn handover, this procedure involves signaling through the AMF, typically used when there is no direct Xn interface between the source and target gNBs.

[0017] The term ‘EPS to 5GS Handover’ refers to a transition of the UE from the Evolved Packet System (EPS) in a 4G LTE network to the 5G System (5GS). This type of handover occurs during inter-RAT mobility when a UE moves from an LTE- connected network to a 5G NR network. It ensures service continuity and enables the UE to take advantage of 5G capabilities.

[0018] The term ‘nudm-uecm message’ refers to any service request or response exchanged between the AMF and the UDM over a Nudm Subscriber Context Management (UECM) service. As defined in existing standards, the nudm-uecm message is used to retrieve subscription data related to mobility and access from theUDM, inform UDM about UE registration, deregistration, or mobility events and update subscription-related state (e.g., access type, RAT type, registration state).

[0019] The term ‘am-policy-create message’ refers to any service request or response sent by the AMF to the PCF over an Npcf AM Policy Control service. As defined in existing standards, the am-policy-create message is used when the AMF needs to create an AM Policy Association for the UE. The am-policy-create message may include the UE's access type, RAT type, subscription data, and network conditions. The am-policy-create message initiates policy control for mobility and registration management.

[0020] The term ‘ue-policy-create message’ refers to the policy association request sent by the AMF to the PCF over an Npcf UE Policy Control service. As define in existing standards, the ue-policy-create message is used to create a UE Policy Association, which carries rules that the UE must follow.

[0021] The term ‘nsmf-pduSession-createSmContext message’ refers to any service request or message that is exchanged between the AMF and SMF over the Nsmf PDU Session service as defined in existing standards. The nsmf-pduSession- createSmContext message is used when the UE requests establishment of a PDU session. The nsmf-pduSession-createSmContext message triggers the SMF to allocate session resources, assign IP addresses, and determine UPF selection.

[0022] The term ‘nsmf-pduSession-updateSmContext message’ refers to the update request sent from the AMF to the SMF whenever a change occurs in the UE’s mobility or session state. As defined in the existing standards, the nsmf-pduSession- updateSmContext message is used for handover scenarios (N2 / N3 / Xn handover, EPG to 5GS handover), RAT type changes, session continuity updates, UE location or access type updates and similar procedures.

[0023] These definitions are in addition to those expressed in the art.BACKGROUND

[0024] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0025] In modern telecommunication networks, ensuring support for diverse device types is vital for maintaining compatibility and delivering seamless services. Among such devices, Reduced Capability (RedCap) devices are designed to provide cost-effective solutions for specific use cases like loT applications, wearables, and industrial sensors. The RedCap devices operate with reduced complexity and lower data rates compared to standard 5G devices, making them suitable for energy-efficient and lightweight applications.

[0026] Current network implementations require development across multiple network functions (NFs), such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Unified Data Management (UDM), and the like, to fully support RedCap devices. This multi- NF dependency introduces challenges in terms of time, cost, and complexity during network upgrades.

[0027] Furthermore, the interaction between RedCap devices and various NFs, each expecting specific signaling and configuration parameters, can complicate integration and deployment processes. For instance, differences in RAT type signaling and handling between RedCap and standard 5G devices may lead to inconsistencies or inefficiencies in network operations.

[0028] Therefore, there is a need for a system and a method that minimizes the aforementioned challenges.SUMMARY OF THE DISCLOSURE

[0029] In an exemplary embodiment, a method for performing one or more network procedures for Reduced Capability (RedCap) devices in a network is described. The method includes receiving, by a primary network function, at least one message from at least one network node. The method includes modifying, by the primary network function, a Radio Access Technology (RAT) type associated with at least one user equipment (UE) from a first RAT type identifier to a second RAT type identifier based on the received at least one message, for communication with a set of network functions. The method includes transmitting, by the primary network function, one or more messages including the modified RAT type to at least one of the set of secondary network functions for performing the one or more network procedures.

[0030] In some embodiments, the one or more network procedures are at least one of a registration procedure, a session establishment procedure, and a handover procedure.

[0031] In some embodiments, the primary network function is an Access and Mobility Management Function (AMF).

[0032] In some embodiments, for modifying the RAT type associated with the at least one UE, the method further includes applying, by the primary network function, a predefined RAT conversion rule, where the predefined RAT conversion rule maps the first RAT type identifier representing an NR RedCap to the second RAT type identifier representing an NR.

[0033] In some embodiments, the one or more messages includes at least one of: a registration message, a policy create message, a session create message, and a session update message.

[0034] In some embodiments, the at least one message includes the first RAT type identifier indicating that the at least one UE is a New Radio (NR) RedCap device.

[0035] In another exemplary embodiment, a system for performing one or more network procedures for Reduced Capability (RedCap) devices in a network is described. The system includes a receiving module and a communication management module at a primary network function, where the communication management module is coupled to the receiving module. The receiving module is configured to receive at least one message from at least one network node. The communication management module is configured to modify a Radio Access Technology (RAT) type associated with at least one User Equipment (UE) from a first RAT type identifier to a second RAT type identifier based on the received at least one message, for communication with a set of network functions. The communication management module is further configured to transmit one or more messages including the modified RAT type to at least one of the set of secondary network functions for performing the one or more network procedures.

[0036] In an exemplary embodiment, the present disclosure discloses a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for performing one or more network procedures for Reduced Capability (RedCap) devices in a network is described. The method includes receiving, by a primary network function, at least one message from at least one network node. The method includes modifying, by the primary network function, a Radio Access Technology (RAT) type associated with at least one user equipment (UE) from a first RAT type identifier to a second RAT type identifier based on the received at least one message, for communication with a set of network functions. The method includes transmitting, by the primary network function, one or more messages including the modified RAT type to at least one of the set of secondary network functions for performing the one or more network procedures.

[0037] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure, and are not restrictive.OBJECTIVES OF THE PRESENT DISCLOSURE

[0038] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0039] An objective of the present invention is to provide a support for Reduced Capability (RedCap) devices in a Fifth Generation (5G) network by implementing enhancements only at an Access and Mobility Management Function (AMF).

[0040] Another objective of the present disclosure is to simplify the network upgrade process by avoiding changes to other network functions (NFs) such as the Session Management Function (SMF), Policy Control Function (PCF), Unified DataManagement (UDM), and others, thereby reducing operational complexity and deployment time.

[0041] Another objective of the present disclosure is to ensure interoperability between the RedCap devices and existing network functions by converting the RAT type from “NR RedCap” to “NR” at the AMF.

[0042] Yet another objective of the present disclosure is to enable execution of one or more network procedures for RedCap devices including registration, policy control, session management, and mobility procedures without requiring modifications to the corresponding other network functions.

[0043] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

[0044] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale; emphasis is instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components, or circuitry commonly used to implement such components.

[0045] FIG. 1 illustrates an exemplary network architecture in which or with which a system configured for performing one or more network procedures for Reduced Capability (RedCap) devices in a network may be implemented, in accordance with embodiments of the present disclosure.

[0046] FIG. 2 illustrates an exemplary block diagram of the system configured performing the one or more network procedures for RedCap devices in the network, in accordance with embodiments of the present disclosure.

[0047] FIG. 3 illustrates another exemplary system architecture configured for performing the one or more network procedures for RedCap devices in the network, in accordance with an embodiment of the present disclosure.

[0048] FIG. 4 illustrates an exemplary flow diagram of a method for performing an NR RedCap UE registration procedure, in accordance with an embodiment of the present disclosure.

[0049] FIG. 5 illustrates an exemplary flow diagram of a method for performing a Protocol Data Unit (PDU) session establishment procedure for the NR RedCap UE, in accordance with an embodiment of the present disclosure.

[0050] FIG. 6 illustrates an exemplary flow diagram of a method for performing a Xn handover procedure for the NR RedCap UE, in accordance with an embodiment of the present disclosure.

[0051] FIG. 7 illustrates an exemplary flow diagram of a method for performing a N2 handover procedure for the NR RedCap UE, in accordance with an embodiment of the present disclosure.

[0052] FIG. 8 illustrates an exemplary flow diagram of a method for performing Evolved Packet System (EPS) to 5GS handover procedure for the NR RedCap UE, in accordance with an embodiment of the present disclosure.

[0053] FIG. 9 illustrates a method flow diagram for the one or more network procedures for RedCap devices in the network, in accordance with an embodiment of the present disclosure.

[0054] FIG. 10 illustrates an exemplary block diagram of a computer system in which or with which embodiments of the present disclosure may be implemented

[0055] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network Architecture102 - User(s)104 -User Equipments (UEs)106 - Network108 - System200 - Block diagram202 - Processor(s)204 - Memory206 -Interface(s)208 - Receiving module210 - Communication management module212 - Database300 - System Architecture302 - gNodeB (gNB)304 - User Plane Function (UPF)306 - Data network (DN)308 - Session Management Function (SMF)310 - Access Management and Mobility Function (AMF)312 - Network Exposure Function (NEF)314 - Policy Control Function (PCF)316 - Unified Data Management (UDM)318 - Binding Support Function (BSF)320 - Authentication Server Function (AUSF)322 - 5G Equipment Identity Register (EIR)324 - Diameter Routing Agent (DRA)326 - Charging Function - Policy Control (CHF-PC)328 - Network Slice Selection Function (NSSF)330 - Signaling Transfer Point (STP)332 - Network Data Analytics Function (NWDAF)334 - Short Message Service Function (SMSF)336 - Gateway Mobile Location Center (GMLC)338 - Location Management Function (LMF)340 - Location Services (LCS) Client400, 500, 600, 700, 800 - Flow Diagram602, 702- Source Next Generation- Evolved Node B (Src-Ng_enodeB)604, 704 - Target gNodeB (Tar gNB)802 - eNodeB804 - Mobility Management Entity (MME)806 - Session Management Function - Gateway Control Plane (SMF GW C)808 - User Plane Function - Gateway User Plane (UPF GW U)810 - Policy Control Function Policy and Charging Rules Function (PCF PCRF) 900 - Method flow Diagram1000 - Computer system1010 - External Storage Device1020 - Bus1030 - Main Memory1040 - Read Only Memory1050 - Mass Storage Device1060 - Communication Port1070 - ProcessorDETAILED DESCRIPTION

[0056] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0057] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0058] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0059] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0060] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0061] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore,the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0062] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0063] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0064] Reduced Capability (RedCap) devices, designed for specific use cases such as loT applications, wearables, and industrial sensors, represent an emerging class of 5G devices with reduced complexity and lower data rates. While these devices offer significant advantages in terms of cost and energy efficiency, their integration into existing networks poses unique challenges.

[0065] Currently, enabling network support for the RedCap devices requires modifications across multiple network functions (NFs), including Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Unified Data Management (UDM), and others. This multi-NF dependency increases the complexity, cost, and time required for network readiness, presenting a barrier to the efficient deployment of RedCap devices.

[0066] To address these challenges, the present disclosure introduces a method and a system to support the RedCap devices by making enhancements at the AMF. Themethod includes converting a Radio Access Type (RAT) type from “New Radio (NR) RedCap” to “NR” within the AMF when communicating with peer nodes such as the SMF, PCF, and UDM. By performing this transformation at the AMF, the network seamlessly support the RedCap devices without requiring changes to other NFs, thereby simplifying deployment, reducing operational overhead, and ensuring compatibility with existing 5G infrastructure.

[0067] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings 1-9.

[0068] FIG. 1 illustrates an exemplary network architecture (100) in which or with which a system (108) configured for performing one or more network procedures for Reduced Capability (RedCap) devices in a network (106) may be implemented, in accordance with embodiments of the present disclosure.

[0069] As illustrated in FIG. 1, the network architecture (100) may include one or more User Equipments (UEs) (104-1, 104-2... 104-N) associated with one or more users (102-1, 102-2... 102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2... 102-N) may be collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2... 104-N) may be collectively referred to as the UE (104) or the UEs (104). Although only three UE (104) are depicted in FIG. 1, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.

[0070] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE (104) may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., a mechanical, a thermal, an electrical, a magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, a smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users (102) and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but not limited to, intelligent, multisensing, network-connected devices, that may integrate seamlessly with each other and / or with a central server or a cloud-computing system or any other device that is network-connected.

[0071] Additionally, in some embodiments, the UE (104) may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playingdevice, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. Further, the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or an entity such as a touchpad, a touch-enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.

[0072] In an embodiment, the one or more UEs (104) may be one or more RedCap devices designed for low-complexity applications requiring reduced data rates. In FIG. 1, the UE (104) may communicate with the system (108) via a network (106) for UE registration, a Protocol Data Unit (PDU) session establishment and a handover procedure. The system (108) is configured to perform one or more network procedures of the UE (104) (the one or more RedCap devices) by enhancing an Access and Mobility Management Function (AMF). Specifically, the system (108) performs a conversion of a Radio Access Technology (RAT) type from “New Radio (NR) RedCap” to “NR” at the AMF level, allowing seamless interaction with peer network functions such as Session Management Function (SMF), Policy Control Function (PCF), and Unified Data Management (UDM). By implementing this, the system (108) ensures that each of the one or more RedCap devices can be supported without requiring modifications to other network functions, thereby simplifying deployment, reducing complexity, and enhancing network efficiency.

[0073] In an embodiment, the network (106) may include at least one of a Fourth Generation (4G) network, a Fifth Generation (5G) network, a Sixth Generation (6G) network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and / or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0074] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or acombination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public- Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0075] In an embodiment, the UE (104) is communicatively coupled with the network (106). The network (106) may receive a connection request from the UE (104). The network (106) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request. Once the connection is established, the system (108) may be configured to perform the one or more network procedures for the RedCap devices. The process for performing the one or more network procedures is explained in greater detail in conjunction with the FIGS. 2 - 10.

[0076] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).

[0077] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) configured for performing the one or more network procedures for the RedCap devices in the network (106), in accordance with embodiments of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1.

[0078] In an embodiment, the system (108) may include one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer- readable storage medium, which may be fetched and executed to perform the one or more network procedures. The memory (204) may include any non-transitory storage device, including, for example, volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.

[0079] In an exemplary embodiment, the system (108) may include one or more modules having functions that may include, but are not limited to, testing, storage, and peripheral functions, such as a receiving module (208), a communication management module (210). In an implementation, the receiving module (208) may be operatively coupled to the communication management module (210) such that the communication management module (210) utilizes information received by the receiving module (208) to execute the one or more network procedures.

[0080] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices (I / O), storage devices, and the like. In an embodiment, the interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, the receiving module (208), the communication management module (210) and a database (212).

[0081] In an embodiment, the receiving module (208) and the communication management module (210) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the receiving module (208) and the communication management module (210). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the receiving module (208) and the communication management module (210) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the receiving module (208) and the communication management module (210) may comprise a processing resource (for example, the one or more processors 202), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the receiving module 208 and the communication management module (210). In such examples, the system (108) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system (108) and the processing resource. In other examples, the receiving module (208) and the communication management module (210) may be implemented by electronic circuitry.

[0082] In an embodiment, the database (212) may store data that may be generated as a result of functionalities implemented by any of the components of the processor (202) or the receiving module (208) and the communication management module (210). In an embodiment, the database (212) may be indicative of including, but not limited to, a relational database, a distributed database, a cloud-based database, or the like.

[0083] In an embodiment, the system (108) may be integrated or associated with a primary network function. For example, the primary network function may be the AMF. The AMF is a core control-plane entity in a 5G network responsible for managing UE registration, authentication, mobility, reachability, and access procedures. The AMF serves as a primary point for handling NAS signaling, maintaining UE context, and coordinating with other network functions.

[0084] In an embodiment, the system (108) is configured to perform the one or more network procedures for RedCap devices. The RedCap devices (interchangeably referred to as New Radio (NR) RedCap device) refers to a class of 5G devices. The RedCap devices are specifically designed to meet the needs of loT applications that do not require the full capabilities of standard 5G. The RedCap devices provide a balance between performance and complexity, making them ideal for various use cases, including wearables, sensors, and surveillance cameras. In an aspect, the one or more network procedures are at least one of a registration procedure, a session establishment procedure, and a handover procedure.

[0085] In an embodiment, in order to perform the one or more network procedures, the receiving module 208 at the primary network function (AMF) is configured to receive at least one message from at least one network node. In an example, the at least one network node may be a Radio Access Network (RAN) (i.e., a gNodeB). The at least one message may be a Non-Access Stratum registration (interchangeably referred to as an N2 message) message. In an aspect, the at least one message may include but is limited to a first Radio access technology (RAT) type identifier indicating that at least one user equipment (UE) such as the UE (104) is a New Radio (NR) RedCap device. The RAT type identifier refers to an indicator used in 5G networks to specify the technology or capability category supported by any UE. In this context, the first RAT type identifier conveys that the at least one UE (104) operates as the NR RedCap device. The first RAT type identifier enables the primary network function (AMF) to distinguish the at least one UE (104) from other UEs (NR) devices. For example, the first RAT type identifier may be represented as ‘NR- RedCap’ in the at least one message.

[0086] In an aspect, the primary network function (AMF) may initially register the at least one UE (104). Upon registration, the primary network function (AMF) may receive a message from the at least one network node (RAN). In some embodiments, upon registration of the UE (104), the primary network function (AMF) may detect whether the at least one UE (104) is an NR RedCap device. The detection is based on analyzing specific subscription information within the at least one message received from the at least one network node (RAN). In an example, initially the at least one UE (104) transmits a Master Information Block (MIB) to the at least one network node (RAN or gNodeB), which includes information regarding its capability of performing as the NR RedCap device. Sequentially, the at least one UE (104) transmits a SystemInformation Block (SIB) to the at least one network node (RAN or gNodeB), confirming RedCap support at the RAN level. Additionally, the at least one UE (104) initiates a random-access procedure by sending a Physical Random-Access Channel (PRACH) preamble to the at least one network node (RAN or gNodeB), including the indication that it is the NR RedCap device. The at least one network node (RAN or gNodeB) responds the at least one UE (104) with a Random- Access Channel (RACH) response. Further, the at least one UE (104) sends a radio resource control (RRC) connection request to the at least one network node (RAN or gNodeB) and establishes the RRC connection, allowing for the transmission of NAS signaling. After completing the RRC connection setup, the at least one UE (104) sends a Registration Request (NAS) message to the RAN (gNodeB). The at least one network node (RAN or gNodeB) forwards this Registration Request message (N2 message) to the primary network function (AMF) via an N2 interface. This message includes the first RAT type identifier which is the RedCap indication, allowing the primary network function (AMF) to identify the at least one UE (104) as the NR RedCap device.

[0087] In an embodiment, upon receiving the at least one message, the communication management module (210) is configured to modify the RAT type associated with the at least one UE (104) from the first RAT type identifier to a second RAT type identifier for communication with a set of secondary network functions. The set of secondary network functions may include but are not limited to a User Plane Function (UPF), a Session Management Function (SMF), a Policy Control Function (PCF), a Short Message Service Function (SMSF), a Unified Data Management (UDM), and a Charging Function (CHF). In order to modify the RAT type of the at least one UE (104), the communication management module (210) at the primary network function (AMF), is configured to apply a predefined RAT conversion rule. The predefined RAT conversion rule maps the first RAT type identifier representing the at least one UE (104) as the NR RedCap device to the second RAT type identifier representing an NR. Further, the communication management module (210) is configured to transmit one or more messages including the modified RAT type to at least one of the set of secondary network functions during a registration, a session establishment, and a handover procedure.

[0088] In an example, when the at least one message received from the at least one network node (i.e., the RAN or gNodeB) contains the first RAT type identifier set to ‘NR RedCap’, the communication management module (210) is configured to perform a RAT-type normalization before forwarding the one or more message to the at least one of the set of secondary network functions. The at least one network node (RAN) may transmit the at least one message (such as a NAS registration request) to the AMF, where the at least one message includes a field such as ‘RAT Type’, ‘AccessType’, or ‘UE Capability RAT Indicator’ that is explicitly marked as NR RedCap. Upon receiving, the communication management module (210) retrieves theRAT-related information element (IE) from the received at least one message. Further, based on the predefined RAT conversion rule the communication management module (210) replaces the value of this field by converting the RAT type indicator from the first RAT type identifier ‘NR RedCap’ to the second RAT type identifier ‘NR’. This modification ensures that any subsequent message generated by the AMF contains the normalized RAT type identifier ‘NR’ instead of ‘NR RedCap’ when transmitted to the set of secondary network functions (SMF, PCF, UDM, SMSF, UPF, CHF, etc.).

[0089] This conversion ensures that the secondary network functions such as the SMF, UPF, PCF, SMSF, which are not upgraded to recognize or process RedCap- specific identifiers, can seamlessly handle the at least one UE (104) as a standard NR device without requiring any modifications. By applying such modifications, the system (108) maintains backward compatibility with existing network nodes while enabling full service support for RedCap devices using only AMF-level enhancements.

[0090] In an aspect, the one or more messages includes at least one of a registration message, a policy create message, a session create message, and a session update message. To further elaborate, during the registration, policy creation, session establishment, session update, or handover procedure, the communication management module (210) ensures that the modified RAT type is included in the one or more messages (such as nudm-uecm, npcf-am-policy-create, npcf-ue-policy-create, nsmf- pduSession-createSmContext, or nsmf-pduSession-updateSmContexttransmitted) to the at least one of the set of secondary network functions such as SMF). This allows the at least one of the set of secondary network functions such as SMF) to handle session-related tasks for the at least one UE (104) (RedCap device) without requiring additional updates or configurations specific to NR RedCap. Further, when the communication management module (210) interacts with the PCF, transmitting the modified RAT type ensures that relevant policies, such as Quality of Service (QoS) levels or bandwidth optimizations, are applied to the at least one UE (104) (RedCap device). This communication also ensures that the at least one UE (104) (RedCap device) receives appropriate service parameters without disruptions. Additionally, the communication management module (210) communicates with the UDM to retrieve and update subscription-related information, ensuring that the converted RAT type is reflected in the UDM records and maintaining consistency across the network (106). Further, the detailed execution of the one or more network procedures is illustrated and described with reference to FIGs. 4 to 9.

[0091] Thus, the system (108) ensures that the at least one UE (104) (RedCap device), are seamlessly integrated and supported into the network (106). This capability eliminates the need for additional hardware or software modifications in other network functions (e.g., the set of secondary network functions), thereby reducing complexity, optimizing resource utilization, and enhancing network efficiency.

[0092] In an embodiment, the system (108) is implemented to perform the 5GS registration, policy control, and session management methods as described in existing standards. In operation, the AMF may receive an Initial UE Message from the RAN, which may include UE capabilities, subscription identifiers, and access-related indications. For RedCap UEs, the gNB includes the ‘NR RedCap UE indication’ as part of the RRC signaling and propagates it to the AMF as defined for reduced capability NR devices.

[0093] In an embodiment, upon receiving the initial UE message, the AMF determines that the UE is a RedCap device based on the access stratum indication received from the RAN. However, in the existing standards where the AMF populates the RatType = ‘NR RedCap’ in the subsequent service-based interface messages, the AMF instead modifies the RAT type and transmits ‘NR’ as the RatType in all downstream interactions. The AMF performs this modification consistently across multiple network procedures

[0094] During the UE registration procedure, the AMF originates a nudm-uecm Registration Update towards the UDM. In standard operation, the payload includes the RAT type corresponding to the UE’s access capabilities. In the present embodiment, instead of including RatType = “NR RedCap”, the AMF transmits RatType = “NR” to the UDM.

[0095] Similarly, during UE Policy association establishment, when the AMF transmits the am-policy-create and ue-policy-create messages to the PCF, the AMF replaces the standard “NR RedCap” RAT value with “NR”. This ensures that policy decisions such as, QoS rules, and session continuity behaviours are evaluated using a non-RedCap RAT context.

[0096] When the UE triggers establishment of a PDU session, the AMF invokes the SMF selection and sends the nsmf-pduSession-createSMContext request. As per existing standards, the AMF populates the RatType based on the UE’s access characteristics. However, in this embodiment, the AMF intentionally transmits RatType = “NR” instead of “NR RedCap”. This modified RAT type influences SMF decisions related to QoS profile assignment, session and service Continuity (SSC) mode selection, and authorized Data Network Name (DNN) handling.

[0097] For Xn-based handover, a target gNB includes the RedCap UE indication in a path switch request sent to the AMF after successful handover. Upon receiving this indication, the AMF updates the session context. However, instead of forwarding RatType = "NR RedCap" in the nsmf-pduSession-updateSMContext message, the AMF again substitutes and sends RatType = “NR” to the SMF. This ensures that the SMF continues treating the session as an NR session, avoiding RedCap-specific constraints or policies during mobility

[0098] During an N2 handover, the target gNB sends the handover request acknowledge containing the NR RedCap UE Indication. The AMF receives thisindication as part of inter-system mobility signaling. However, in the subsequent nsmf- pduSession-updateSMContext, the AMF does not propagate “NR RedCap”. Instead, the AMF transmits RatType = “NR” to maintain a uniform RAT representation across the core network functions.

[0099] In an EPS to 5GS mobility scenario, the target NG-RAN node indicates the RedCap characteristics in the Handover Request Acknowledge sent to the AMF, The AMF intentionally remaps the RAT type before interacting with the SMF. Thus, in the nsmf-pduSession-updateSMContext, the AMF sends RatType = “NR” instead of “NR RedCap”. This prevents the SMF from applying RedCap-specific restrictions during migration from EPS to 5GS.

[0100] Although FIG. 2 shows exemplary components of the system (108), in other embodiments, the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other components of the system (108).

[0101] FIG. 3 illustrates another exemplary system network architecture (300) configured for performing the one or more network procedures for RedCap devices in the network (106), in accordance with an embodiment of the present disclosure. FIG. 3 is explained in conjunction with FIG. 1 and FIG. 2.

[0102] The network architecture (300) includes the UE (104) (referred to as the at least one UE (104) in FIG. 2), the RAN (gNB) (302) (referred to as the at least one network node in FIG. 2), the UPF (304), a data network (DN) (306), the SMF (308), the AMF (310), a Network Exposure Function (NEF) (312), the PCF (314), the UDM (316), a Binding Support Function (BSF) (318), an Authentication Server Function (AUSF) (320), a 5G Equipment Identity Register (EIR) (322), a Diameter Routing Agent (DRA) (324), a Charging Function - Policy Control (CHF-PC) (326), a Network Slice Selection Function (NSSF) (328), a Signaling Transfer Point (STP) (330), a Network Data Analytics Function (NWDAF) (332), the SMSF (334), a Gateway Mobile Location Center (GMLC) (336), a Location Management Function (LMF) (338), and a Location Services (LCS) Client (340).

[0103] In one aspect, the network architecture (300) may include a fifthgeneration (5G) core (5GC) network. The network architecture (300) may include advanced generations (e.g., 6G and so on).

[0104] In an aspect, the RAN (gNB) (302) is the 5G base station in the RAN of the network. The RAN (gNB) (302) serves as an access point between the UE (104) and the 5G core network. The RAN (gNB) (302) provides wireless communication, manages radio resources, and ensures the connection between the UE (104) and the rest of the network.

[0105] In an aspect, the UPF (304) is a network element in the 5G core network that is responsible for managing the user plane traffic, i.e., the actual data (such as internet browsing, video streaming, etc.) that is transmitted between the UE (104) and the internet or other network services. The UPF (304) performs functions (e.g., packet forwarding, traffic management, NAT (Network Address Translation), mobility anchoring, and QoS management) to ensure efficient and secure data transmission. The UPF (304) works with other network elements (e.g., the SMF (308), AMF (310), and PCF (314)) to seamlessly handle the user data, support network slicing, and facilitate advanced features in the network.

[0106] In an aspect, the DN (306) refers to external networks that provide services and applications to users (via UE 104) through the network (106). The networks can be public or private and include services such as the Internet, enterprise networks, cloud services, or any other network where the user data might be sent or received. The DN (306) provides external resources, including services (e.g., web browsing, cloud applications, loT services, or any form of internet access) that the UE (104) can access. The DN (306) is connected to the network via the UPF (304), which routes data between the UE (104) and the DN (306). The UPF (304) facilitates the connection between the UE (104) and the DN (306), enabling user data flow. The DN (306) can vary based on the use case (public or private), and its integration with the network enables high-performance, secure, and efficient communication for users accessing external services.

[0107] In an aspect, the SMF (308) is a network element responsible for managing user sessions. The SMF (308) ensures that the UE (104) has the appropriate resources, connectivity, and quality of service (QoS) to maintain data sessions while connecting to the network. The SMF (308) interacts with other network elements / functions to manage session setup, modification, and release, as well as ensure proper routing of data between the UPF (304) and the UE (104).

[0108] In an aspect, the AMF (310) is a network element responsible for handling access management and mobility management. The AMF (310) interacts with other network elements to ensure secure and seamless connection, mobility, and session management for the UE (104) in a 5G network. The AMF (310) handles initial access requests from the UE (104) when the UE (104) first tries to connect to the network. The AMF (310) tracks the UE’s location as the UE moves across different network cells or regions. The AMF (310) handles location updates and handover management when the UE (104) moves from one cell to another, ensuring continuous connectivity without service interruptions. The AMF (310) works with the Session Management Function (SMF) (308) and the User Plane Function (UPF) (316) to handle the session continuity when the UE (104) moves between different network slices or access points. The AMF (310) handles the authentication of the UE during the registration process, working with the AUSF (320) to validate the user's identity andcredentials (such as SUPI or SUCI). Once the authentication is successful, the AMF (310) allows the UE (104) to access network services.

[0109] In an aspect, the system (108) is implemented or embedded in the AMF (310). The AMF (310) converts the RAT type from 'NR RedCap' to 'NR' when communicating with peer nodes other than RAN. The AMF (310) receives indication from the RAN in initial UE attachment procedure that the UE ( 104) is a RedCap device. Further, the AMF (310) transmits the one or more message including the modified RAT type to the other NFs during the registration, PDU establishment, and handover procedures.

[0110] For example, during registration, instead of sending RAT type as ‘NR RedCap’ in nudm-uecm message to UDM (316), the AMF (310) sends RAT type as ‘NR’. The nudm-uecm message is a service request or response exchanged between the AMF (310) and the UDM (316) over a Nudm Subscriber Context Management (UECM) service. As defined in existing standards, the nudm-uecm message is used to retrieve subscription data related to mobility and access from the UDM (316), inform UDM (316) about UE registration, deregistration, or mobility events and update subscription-related state (e.g., access type, RAT type, registration state).

[0111] Further, instead of sending RAT type as ‘NR RedCap’ in am-policy create message to PCF (314), the AMF (310) sends RAT type as ‘NR’ . Further, instead of sending RAT type as ‘NR RedCap’ in ue-policy create message to the PCF (314), the AMF (310) sends RAT type as ‘NR’. The ue-policy-create message is the policy association request sent by the AMF (310) to the PCF (314) over an Npcf UE Policy Control service. As define in existing standards, the ue-policy-create message is used to create a UE Policy Association, which carries rules that the UE (104) must follow.

[0112] Similarly, during the PDU establishment procedure, instead of sending RAT type as ‘NR RedCap’ in nsmf-pduSession-createSmContext message to the SMF (308), the AMF (310) sends RAT type as ‘NR’. The nsmf-pduSession- createSmContext message a service request or message that is exchanged between the AMF (310) and SMF (308) over the Nsmf PDU Session service as defined in existing standards. The nsmf-pduSession-createSmContext message is used when the UE (104) requests establishment of a PDU session. The nsmf-pduSession-createSmContext message triggers the SMF (308) to allocate session resources, assign IP addresses, and determine UPF (304) selection.

[0113] Similarly, during the Xn handover, instead of sending RAT type as ‘NR RedCap’ in nsmf-pduSession-updateSmContext message to SMF (308), the AMF (310) sends RAT type as ‘NR’. Similarly, during the N2 handover instead of sending RAT type as ‘NR RedCap’ in nsmf-pduSession-updateSmContext message to SMF (308), the AMF (310) sends RAT type as ‘NR’. The nsmf-pduSession- updateSmContext message is the update request sent from the AMF (310) to the SMF (308) whenever a change occurs in the UE’s mobility or session state. As defined inthe existing standards, the nsmf-pduSession-updateSmContext message is used for handover scenarios (N2 / N3 / Xn handover, EPG to 5GS handover), RAT type changes, session continuity updates, UE location or access type updates and similar procedures.

[0114] Similarly, during the EPS to 5GS handover, instead of sending RAT type as ‘NR RedCap’ in nsmf-pduSession-updateSmContext message to SMF (308), the AMF (310) sends RAT type as ‘NR’.

[0115] In an aspect, the NEF (312) is a network element that provides a secure interface for exposing network capabilities and services to external entities (e.g., third- party applications or service providers). The NEF (312) acts as a gateway to allow authorized applications to access network data and capabilities while ensuring the security and privacy of the network and the users.

[0116] In an aspect, the PCF (314) is a network element that manages policy and charging control. The PCF (314) ensures the appropriate Quality of Service (QoS) and traffic management for users and services based on dynamic policies set by the network operator. The PCF (314) is responsible for providing real-time decisions on how network resources should be allocated, how traffic should be prioritized, and how services should be delivered based on various criteria like application type, user preferences, or network conditions.

[0117] In an aspect, the UDM (316) is a network element responsible for managing user-related data and subscription information and subscriber authentication, authorization, mobility management, and other critical services. By storing and processing user profiles, the UDM (316) ensures secure and efficient access to network services while facilitating subscriber management and service delivery.

[0118] In an aspect, the BSF (318) is a network element used in management of user bindings for mobility and session management. The BSF (318) ensures that the user equipment’s identity and context are properly handled as the UEs move across different network slices or access points in the network. The BSF (318) manages user bindings between a user’s identity and their current context regarding mobility, session management, and network access. The BSF (318) supports mobility management, session continuity, and seamless handovers between different network access points or slices by maintaining accurate and up-to-date binding information. The BSF (318) ensures that the network functions (e.g., AMF (310), SMF (308), PCF (314), and UPF (304)) can efficiently handle the user’s session and provide consistent service quality as the user moves across the network.

[0119] In an aspect, the AUSF (320) is a network element that handles the authentication of the UE (104) when the UE (104) tries to access the network (106). The AUSF (320) plays a vital role in ensuring network security by verifying the identity of users and protecting the integrity of the network. The AUSF (320) communicates with the UE (102) via the AMF (310) to perform the authentication process. The AUSF (320) verifies the identity of the UE (104) based on credentials (e.g., Subscription 1Permanent Identifier (SUPI) or Subscription Concealed Identifier (SUCI) stored in the UDM (316). In an aspect, the SUPI is an identifier in the network used to identify a subscriber (i.e., the user (102) or UE (104)). The SUPI is an essential element in the authentication and identification processes within the network. The SUPI serves as the permanent, globally unique identity of a subscriber. The AUSF (320) uses the SUPI to identify the UE (104) when the UE (104) attempts to connect to the network or during authentication procedures. The network operator typically assigns the SUPI and stays the same throughout the subscriber’s time in the network, making the SUPI a long-term identifier. In an aspect, the SUCI is a privacy-enhanced version of the SUPI used in the network. The SUCI is generated by encrypting the SUPI to protect the subscriber’s identity and prevent the SUCI from being exposed during communication between the UE (104) and the network (106).

[0120] In an aspect, the 5G EIR (322) is a network element in the telecommunication networks that manages and tracks the identity of mobile devices (user equipment, or UE) based on their unique identifiers, such as International Mobile Equipment Identity (IMEI) number. The 5G EIR (322) helps ensure network security, prevent fraud, and maintain the integrity of the network.

[0121] In an aspect, the DRA (324) is a network element that routes Diameter signaling messages between network functions, enabling authentication, authorization, accounting, charging, and policy control. Diameter is a protocol for authentication, authorization, accounting (AAA), and policy control in various network services. The DRA (324) ensures efficient message routing between the network functions and legacy systems, helping to maintain interoperability across network generations and supporting scalable, reliable network operations.

[0122] In an aspect, the CHF-PC (326) is a network element used in charging and policy control. The CHF-PC (326) is responsible for enforcing charging rules and ensuring that network services, such as data usage, voice, and SMS, are billed correctly while also applying policy rules that govern how network resources are allocated. The CHF-PC (326) is responsible for handling both the charging and policy control aspects of the network. The CHF-PC (326) ensures that the PCF (314) and the CHF work together to apply consistent and synchronized rules for both quality of service (QoS) and billing.

[0123] In an aspect, the NSSF (328) is a network element responsible for selecting the appropriate network slice for a user or a service based on their specific requirements. A network slice is a logically isolated, customized virtual network tailored to meet specific service needs, such as low-latency communications, high bandwidth, or massive connectivity for loT devices. The NSSF (328) ensures that each user or service is connected to the correct network slice based on a plurality of factors, such as application requirements, user preferences, and network capabilities.

[0124] In an aspect, the STP (330) is a network element in a Signaling System 7 (SS7) and the network responsible for routing signaling messages between different network elements. The STP (330) is an intermediary that efficiently routes signaling messages to the correct destination based on the signaling protocol and routing tables. The STP (330) forwards signaling messages between the network nodes (e.g., Mobile Switching Centers (MSCs), Home Location Registers (HLRs), the SMSCs and the GMSC. The STP (330) also routes signaling messages between the network elements / functions (e.g., the AMF (310), the SMF (308), and the UPF (304)). Further, the STP (330) is responsible for routing signaling messages, ensuring interoperability between different network elements, and performing functions (e.g., protocol conversion, security, and load balancing). The STP (330) routes signaling messages between the network functions and provides interoperability with legacy systems. By enabling efficient signaling, the STP (330) ensures seamless connectivity, mobility, and communication across different generations of mobile networks.

[0125] In an aspect, the NWDAF (332) is a network element responsible for collecting, analyzing, and providing insights based on network data to optimize network operations, improve performance, and enable data-driven decision-making. The NWDAF (332) performs network management and enhances the network's overall efficiency by supporting key functions (e.g., traffic management, quality of service (QoS), network slice optimization, and predictive maintenance).

[0126] In an aspect, the SMSF (334) is a network element responsible for managing and delivering Short Message Service (SMS) in the 5G environment. The SMSF (334) handles SMS operations to ensure the correct delivery of text messages between users, applications, and networks. The SMSF (334) provides interoperability for SMS across different generations of telecommunication network technologies. The SMSF (334) is responsible for SMS routing, interworking with legacy Short Message Service Centers (SMSCs), session management, and SMS storage when the recipient is unavailable. The SMSF (334) ensures SMS continuity, even for roaming users, and supports SMS over IP, providing a seamless messaging experience in the network.

[0127] In an aspect, the GMLC (336) is a network element in the telecommunication network to support the Location-Based Services (LBS). The GMLC (336) is an interface between the mobile network and external Location-Based Services (LBS) providers (e.g., emergency services, navigation applications, or asset tracking systems). The GMLC (336) handles requests for location information and ensures that the GMLC (336) is securely relayed to the requesting service.

[0128] In an aspect, the LMF (338) is a core network function responsible for managing the location of the UE (104) to support services (e.g., mobility management, handovers, and location-based services). The LMF (338) tracks and updates the geographical location of the UE (104) (e.g., mobile devices) within the network, such as the network (106). The LMF (338) calculates the UE’s location based on an internalalgorithm and data received from the UE (104) or RAN (gNB) (302). The LMF (338) supports location-based services (e.g., real-time location sharing, navigation, or emergency services), ensuring that the location of the UE (104) is accurately known and managed.

[0129] In an aspect, the LCS Client (340) refers to a device or application that requests and uses location-based services provided by the network. The LCS client (340) interacts with the network to obtain the geographical location of the UE (104) for various services. The LCS client (340) requests location data, such as the geographical position of the UE (104) from the network (106).

[0130] An NL7 interface is an interface that enables the communication between the LMF (338) and other location-related functions for location services in an Internet protocol (IP) Multimedia Subsystem (IMS). In an aspect, the IMS is an architecture for delivering multimedia services over the IP networks. The IMS is a framework that enables the integration and delivery of services such as voice, video, messaging, and data through the Internet Protocol (IP).

[0131] An NL1 interface is an interface used between the LMF (338) and the AMF (310). The NL1 manages user mobility and authentication during the registration and handover processes. The NL1 interface allows the LMF (338) and the AMF (310) to handle location and mobility management and ensures a smooth user experience as the UE (104) moves through the network and maintains its active session.

[0132] A NL2 interface is a communication interface between the GMLC (336) and the AMF (310) in the network to support the location-based services (LBS) to provide location information for emergency services, tracking, and other locationdependent services. The NL2 interface enables the exchange of information for session establishment, mobility management, QoS enforcement, and bearer resource control. The NL2 interface ensures a smooth user experience during mobility events, maintains consistent session quality, and efficiently manages the network’s resources as users move through different cells or network slices.

[0133] An NL5 interface is an interface between the GMLC (336) and the NEF (312). The NL5 interface enables the exchange of subscriber-related data, policy parameters, and location service configurations required for processing location requests initiated by the UE (104) or external LCS clients.

[0134] An NL6 interface is an interface between the GMLC (336) and the UDM (316). The NL6 interface communicates the location data when location-based services or subscriber-related information is required for delivering accurate location data. When a location request is made (e.g., an emergency call or a location-based service query), the GMLC (336) may need to authenticate and authorize the UE (104). The UDM (316) stores the subscriber’s profile and authentication data, including subscription information, credentials, and access rights. The NL6 interface allows theGMLC (336) to query the UDM (316) to validate the subscriber and ensure they are authorized for the requested location service.

[0135] A NL17 interface is an interface between the 5G EIR (322) and the AMF (310) for managing the security and integrity of the UE (104) attempting to access the network (106). When the UE (104) tries to connect to the network (106), the AMF (310) communicates with the 5G EIR (322) via the NL17 interface to verify the IMEI of the UE (104). The NL17 interface helps in maintaining network security by facilitating communication between the EIR (322) and the AMF (310) to authenticate devices, ensuring that only authorized and non-compromised UEs can access the network. This helps prevent fraud and unauthorized access while ensuring the integrity of the network.

[0136] A N12 interface is an interface between the AUSF (320) and the AMF (310) used for the authentication and security procedures during the initial registration and mobility management of the UE (104) in the network (106). In an aspect, the AMF (310) sends an authentication request to the AUSF (320) via the N12 interface, which then communicates with the UDM (316) to verify the credentials (e.g., IMSI) and check if the UE (104) is authorized to access the network. The N12 interface ensures that only authorized users or UEs are granted access to the network and supports the exchange of vital authentication information during the UE’s registration or mobility management process. The N12 interface helps ensure a robust and secure network by coordinating the authentication procedure and providing a secure mechanism for validating user identity.

[0137] An N13 interface is an interface between the AUSF (320) and the UDM (316) used for the authentication process of the UE ( 104) and ensures that the UE ( 104) trying to connect to the network is legitimate and authorized to access services. The N13 interface supports the AUSF (320) in retrieving authentication data necessary for verifying the identity of the UE (104) from the UDM (316) to ensure secure and authenticated access to the network (106). By facilitating the exchange of sensitive subscriber information and authentication vectors, the N13 interface helps to maintain the overall security and integrity of the network.

[0138] An N8 interface is an interface between the UDM (316) and the AMF (310) responsible for supporting network procedures (e.g., subscriber management, authentication, and service access). The N8 interface facilitates communication between the AMF (310) and the UDM (316) to retrieve or update the subscriber's profile during registration, authentication, or mobility management procedures.

[0139] An N14 interface is an interface used by the AMF (310) for coordinating session management and mobility management, enabling these two core network functions to work together in supporting the user's session, particularly during handovers or mobility events. The N14 interface facilitates the exchange of information required for session management, mobility management, and bearer resourcemanagement. It ensures that user sessions are maintained without interruption, even as the user moves across different areas of the network. Additionally, the N14 interface supports the enforcement of QoS and policy rules, ensuring seamless session continuity and high-quality service delivery.

[0140] An N1 interface is an interface between the AMF (310) and the UE (104) responsible for handling registration, authentication, mobility management, and session management functions between the UE (104) and the network (106). Through the N1 interface, the AMF (310) ensures the UE's connectivity, handles user session continuity, and enables efficient mobility management as the UE (104) moves within the network.

[0141] An N2 interface is an interface between the AMF (310) and the RAN gNB (gNodeB) (302) used for supporting mobility management, session management, and radio resource control between the AMF (310) and the RAN gNB (302), ensuring seamless connectivity and user experience as the UE (104) moves across the network (106).

[0142] An N3 interface is an interface between the RAN gNB (gNodeB) (302) and the UPF (304) responsible for handling the data traffic (user plane traffic) between the UE (104) and the network. The N3 interface facilitates the transfer of user data, ensuring that data flows efficiently between the radio access network (RAN) and the network. The N3 interface supports the routing and forwarding of user traffic, bearer resource management, and the enforcement of QoS policies. The N3 interface ensures that user data is delivered efficiently and with high service quality from the UE (104) to its destination, whether within the network or externally. By handling data tunneling and forwarding, the N3 interface helps maintain a continuous and high-quality user experience during data transmission.

[0143] An N6 interface is an interface between the UPF (304) and the DN (306) that facilitates the transfer of user data between the Network and external data networks (e.g., the internet, private servers, or application networks). In an operative aspect, the UPF (304) receives user data from the gNB (302) (via the N3 interface) and forwards the received user data through the N6 interface to the DN (306).

[0144] An N4 interface is an interface between the SMF (308) and the UPF (304) for managing user sessions and handling user plane data for optimal user experience in traffic routing, session management, and quality of service (QoS) enforcement. The N4 interface allows the SMF (308) to control the data path and session parameters for users, ensuring that traffic flows efficiently through the network and that user sessions are maintained with the appropriate resources.

[0145] A N16 interface is an interface used by the SMF (308) for service data flow (SDF) management. The N16 interface is responsible for the interaction between the SMF (308) and the application functions (AFs), such as service platforms or applications that require session management and data flow control. The N16 interfaceenables the SMF (308) to enforce application-specific policies, manage QoS requirements, and dynamically adjust session parameters based on the service or application the user is accessing. By allowing the AF to provide policy information, the N16 interface ensures that user sessions are optimized for the specific needs of each service, leading to a more tailored and efficient user experience.

[0146] A Ni l interface is an interface between the AMF (310) and the SMF (308) for managing session establishment, modification, and termination, as well as handling mobility management and user authentication across the network. The Ni l interface allows the AMF (310) to manage the UE’s mobility, ensure correct bearer allocation, and communicate with the SMF (308) for session-related activities (e.g., session establishment, modification, and release). The Ni l interface ensures that user sessions are properly managed and that QoS policies are enforced throughout the session, enhancing the overall user experience in the network.

[0147] A N10 interface is an interface between the UDM (316) and the SMF (308) for managing subscription data and session information related to user services, such as retrieving subscriber profiles and policy information and ensuring that the session is established and maintained according to the subscriber's preferences and network policies. The N10 interface facilitates the exchange of subscriber profile information between the SMF (308) and the UDM (316). The SMF (308) retrieves user profile data from the UDM (316), such as the subscriber’s service preferences, QoS requirements, or subscription details, to properly manage sessions and bearers.

[0148] A N15 interface is an interface between the PCF (314) and the AMF (310) responsible for enabling the AMF (310) to interact with the PCF (314) for policy control and decision-making related to mobility management and session management for the UE. The N15 interface helps the AMF (310), and the PCF (314) to enforce the QoS policies and ensure that the appropriate policies are applied to the users' sessions based on their behavior, subscription, and network conditions.

[0149] A N22 interface is an interface between the AMF (310) and the NSSF (328) that enables the AMF (310) to interact with the NSSF (328) to obtain information about network slice selection for a particular UE or session. This interaction ensures that the appropriate network slice is selected for the UE (104) based on subscription, service requirements, and network conditions.

[0150] A N21 interface is an interface between the UDM (316) and the SMSF (334) that enables the SMSF (334) to interact with the UDM (316) to manage Short Message Service (SMS) functionality, particularly for storing, retrieving, and processing subscriber-related data and settings related to SMS services. The N21 interface enables the SMSF (334) to access and manage subscriber information related to SMS services. Through the N21 interface, the SMSF (334) can retrieve the necessary subscriber profiles, manage SMS service activation and deactivation, handle message routing, and ensure that SMS services are properly authorized and authenticated. TheN21 interface ensures that SMS functionality is properly aligned with the network policies and subscriber preferences, enabling effective SMS message handling for users in the network.

[0151] A N20 interface is an interface between the SMSF (334) and the AMF (310) for effective management of SMS services. The N20 interface facilitates the exchange of information related to SMS delivery, mobility management, and session management. Through the N20 interface, the AMF (310) and SMSF (334) ensure that SMS messages are delivered correctly, even when the UE (104) is moving between cells or undergoing other mobility events. The N20 interface helps maintain the integrity of SMS services by ensuring that mobility context, delivery status, and subscriber preferences are communicated between the two functions to provide seamless SMS service.

[0152] A N23 interface is an interface between the PCF (314) and the NWDAF (332), enabling the PCF (314) to incorporate real-time network data and analytics into its policy control decisions. The PCF (314) is responsible for enforcing policy decisions within the network, such as Quality of Service (QoS), service prioritization, and charging rules. The NWDAF (332) gathers and analyzes network data to provide insights on network conditions, user behavior, and performance. The N23 interface allows the PCF (314) to request and receive network data from the NWDAF (332) to inform its policy decisions. By leveraging insights provided by the NWDAF (332), the PCF (314) can dynamically adjust policies to optimize network performance, service quality, and resource utilization. The N23 interface helps ensure that policies are context-aware and responsive to changing network conditions, enhancing overall user experience and network efficiency.

[0153] A N34 interface is an interface between the NWDAF (332) and the NSSF (328) that facilitates the exchange of data related to network slicing and network performance analytics. By providing detailed network analytics (including slice performance, traffic forecasting, and load balancing data), the NWDAF (332) ensures that the NSSF (328) can select an appropriate network slice for each UE or network service. This improves network efficiency, enhances quality of service (QoS), and helps balance network resources to meet varying demands in the network.

[0154] A N40 interface is an interface between the SMF (308) and the CHF- PC (326) for enabling accurate charging and policy enforcement in the network. The N40 allows for the real-time exchange of charging data, policy control decisions, and service usage reports. By using the N40 interface, the SMF (308) and CHF-PC (326) work together to ensure that users are billed appropriately for their network usage and that network policies are adhered to during the lifecycle of a user session.

[0155] A N28 interface is an interface between the PCF (314) and the CHF-PC (326) that facilitates the exchange of charging and policy control information, ensuring that policy decisions made by the PCF (314) are aligned with charging rules managedby the CHF-PC (326). The N28 interface ensures that quality of service (QoS), traffic management, and charging policies are enforced consistently across the network. By enabling the PCF (314) and CHF-PC (326) to exchange policy decisions and charging rules, the N28 interface ensures that service usage is accurately billed in real time, according to the policies applied by the PCF (314). The N28 interface facilitates the exchange of charging data and real-time updates, ensures that users are billed correctly for the services consumed, and that quality of service (QoS) levels are maintained across the network.

[0156] A N52 interface is an interface between the UDM (316) and the NEF (312) that enables the UDM (316) to expose relevant subscriber data and authentication information to other network functions or external applications via the NEF (312). The NEF (312) acts as an intermediary allowing controlled and secure data access from network functions like the UDM (316). The N52 interface is used for providing subscriber-related data (e.g., authentication details, subscription information, and other user-related data) to third-party services or applications that require such data for certain functionalities (e.g., network slicing, quality of service enforcement, or policy decisions).

[0157] A N29 interface is an interface between the SMF (308) and the NEF (312) for providing session-related information and policy decisions from the SMF (308) to external network entities and third-party applications via the NEF (312). The N29 interface facilitates the exchange of relevant data about user sessions, service usage, and network conditions in a controlled and secure manner. Further, the N29 interface allows third-party applications or network services to interact with network functions in a way that aligns with operator policies and ensures privacy and security.

[0158] An interface between the NEF (312) and the BSF (318) used for binding and authentication purposes, facilitating the interaction between the NEF (312) and BSF (318) to expose relevant binding and user context information to third-party services or applications securely. The interface between the NEF (312) and the BSF (318) acts as an intermediary between the NEF (312) and the BSF (318) such that the NEF (312) exposes the binding data from the BSF (318) to authorized external services while ensuring security, privacy, and policy enforcement. The interface between the NEF (312) and the BSF (318) is useful in location-based services, mobility management, authentication or authorization of external applications, and network slice management.

[0159] A N51 interface is an interface between the AMF (310) and the NEF (312) that enables the AMF (310) to expose mobility management and authentication data to external applications or services via the NEF (312). The N51 interface supports location-based services, authentication services, network slice management, and policy enforcement. By facilitating the secure and controlled exposure of mobility data, authentication context, and policy information, the N51 interface enables third-partyapplications to interact with the network. Further, the N51 ensures that sensitive network data is shared only with authorized entities and is used in compliance with privacy and security policies, helping to deliver a wide range of services while maintaining network integrity and user privacy.

[0160] A SGd interface is an interface between the SMSF (334) and the DRA (324) that supports SMS routing, message delivery, and policy enforcement within the network. By using Diameter signaling, the SGd interface allows the SMSF (334) to interact with the DRA (324) for functions (e.g., user profile retrieval, SMS routing decisions, charging, and accounting). The SGd interface enables the network to deliver SMS services efficiently and securely, ensuring correct message routing, billing, and policy enforcement. Further, the SGd interface manages network resources and ensures that SMS traffic is processed according to operator-defined rules and subscriber preferences.

[0161] A signaling transport (SIGTRAN) interface / protocol is an interface between the SMSF (334) and the STP (330) for facilitating signaling related to the Short Message Service (SMS) within the network and for routing and transferring SMS-related signaling messages across different parts of the network and the SS7 networks. The SIGTRAN facilitates the routing of SMS messages, user profile handling, delivery confirmation, and charging through Diameter and SS 7-based signaling adapted for IP transport.

[0162] A Gy, Sy interface is a signaling interface used between the CHF -PC (326) and the DRA (324) for managing charging and policy control operations related to user sessions and data flows. The Gy, Sy interface ensures that Diameter signaling for charging, policy enforcement, and QoS is efficiently routed between the CHF -PC (326) and other network components (e.g., policy and Charging Rules Function (PCRF), home subscriber server (HSS), and billing systems. By handling the interactions between the CHF-PC (326) and the DRA (324), the Gy, Sy interface enables the effective application of charging rules and policy enforcement in the network. In an aspect, the PCRF is a network element that manages policy control and charging rules and ensures that the correct policies for service quality, bandwidth allocation, and charging are applied to user sessions and data traffic. In an aspect, the HSS is a central database in telecommunications networks, storing subscriber profiles and authentication information. The HSS manages and stores key data about subscribers, such as their service subscriptions, preferences, and authentication credentials, and provides this data to other network elements (e.g., the PCRF and IMS).

[0163] In an aspect, a Sd interface is an interface between the PCF (314) and the DRA (324) responsible for ensuring that policy decisions made by the PCF are properly enforced and charging information is accurately routed and exchanged between various network components (e.g., PCRF, CHF (Charging Function), and billing systems).

[0164] In an aspect, a primary Rx interface is an interface between the PCF (314) and the BSF (318) for managing policy control and binding information related to user data sessions and mobility management. The primary Rx interface enables the PCF (314) to access and utilize binding information provided by the BSF (318) for efficient policy enforcement. Further, the primary Rx interface supports seamless session continuity, ensures consistent QoS, and enables effective mobility management. The PCF (314) uses the binding data to enforce policies dynamically based on a user's location, network conditions, and session state.

[0165] In an aspect, a secondary Rx interface is an interface between the DRA (324) and the BSF (318) for the Diameter-based signaling in the network. The DRA (324) facilitates the routing of Diameter messages related to binding information stored and managed by the BSF (318). The diameter messages ensure policy enforcement, session continuity, and mobility management in the network. The secondary Rx interface between the DRA (324) and the BSF (318) ensures that charging rules and quality of service (QoS) policies are applied consistently and accurately to user sessions by enabling the necessary information exchange between the DRA (324) and BSF (318).

[0166] In an aspect, the Le interface is an interface between the GMLC (336) and the LCS Client (340) used to exchange location-related information. The GMLC (336) handles location-based services (LBS), while the LCS Client (340) typically refers to the application or entity that requests location services for the users. The Le interface between the GMLC (336) and the LCS Client (340) allows the LCS Client (340) to request location data from the GMLC (336), which processes the request and returns the relevant location information. The Le interface supports various service types, privacy controls, and location accuracy requirements, ensuring that location data is provided securely and in accordance with the user’s permissions.

[0167] FIG. 4 illustrates an exemplary flow diagram (400) of a method for an NR RedCap UE registration procedure, in accordance with an embodiment of the present disclosure. FIG. 4 is explained in conjunction with FIG 1, FIG.2 and FIG.3.

[0168] In an embodiment, the flow diagram (400) depicts the interactions between various network entities, including the UE (104), the gNodeB (302), the AMF (310), the EIR (322) (referred to as 5G EIR in FIG. 3), the PCF (314), the AUSF (320), the UDM (316), and the SMF (308).

[0169] To initiate the NR RedCap UE registration procedure, at step 402, the UE (104) transmits a Master Information Block (MIB) to the gNodeB (302), which includes support information for the one or more RedCap devices. This is followed by the transmission of a System Information Block (SIB) from the UE (104) to the gNodeB (302) at step 404, confirming RedCap support at the RAN level.

[0170] At step 406, the UE (104) initiates the random-access procedure by sending a physical random-access channel (PRACH) preamble to the gNodeB (302),including an indication that it is a RedCap device. The gNodeB (302) responds with RACH response at step 408.

[0171] At step 410, the UE (104) then sends the RRC connection request to the gNodeB (302) and establishes the RRC connection at step 412, allowing for the transmission of NAS signaling.

[0172] After completing the RRC connection setup at step 412, the UE (104) sends a Registration Request (NAS) message to the gNodeB (302) at step 414. The gNodeB (302) forwards this Registration Request message to the AMF (310) via the N2 interface at step 416. This message includes the RedCap indication, allowing the AMF (310) to identify the UE (104) as a RedCap UE during registration.

[0173] At step 418, the AMF (310) interact with the UE (104) for the UE authentication as per the existing standard authentication process. In an embodiment, the AMF (310) modifies the RAT type associated with the UE (104) (NR RedCap device) during the subsequent registration and policy creation steps (for example, at steps 420 to 424) to ensure compatibility with secondary network functions.

[0174] For example, at step 420, instead of sending the RAT type as "NR RedCap" to the UDM (316), the AMF (310) sends the RAT type as "NR" in the Nudm_UECM registration message. This ensures that the UDM (316) processes the UE (104) as a standard NR device, simplifying data handling and avoiding potential compatibility issues.

[0175] At step 422, the AMF (310) performs a Nudm_SDM Get request to retrieve and subscribe to the UE’s subscription data from the UDM (316) to ensure that updated and accurate subscription information is available. Following step 424, the AMF (310) performs a Nudm_SDM Subscribe operation, enabling it to receive dynamic updates to the subscription data from the UDM (316).

[0176] At step 426, the AMF (310) initiates the AM Policy Association Establishment with the PCF (314). Similar to the UDM (316) interaction, the AMF (310) sends the RAT type as “NR” instead of “NR RedCap” to update the policy application. For example, the AMF (310) sends RatType as ‘NR’ in AM-policy create message to the PCF (314).

[0177] At step 428, the AMF (310) sends the UE Policy Association Establishment request to the PCF (314), again using the RAT type as “NR”. This ensures that the policies assigned to the UE (104) align with those of standard NR devices, simplifying processing and avoiding the need for additional configurations for RedCap-specific policies. For example, the AMF (310) sends RatType as ‘NR’ in ue- policy create message to PCF (314).

[0178] Once all interactions with the secondary set of network functions are complete, the primary network function (e.g., the AMF (310)) sends a Registration Accept message to the UE (104) at step 430. This message indicates the successfulregistration of the UE (104). In response, the UE (104) sends a Registration Complete message, confirming that the registration process is completed, at step 432.

[0179] In an overall aspect, for the NR RedCap UE registration procedure instead of sending RatType as ‘NR RedCap’ in Nudm_UECM registration message to the SMF (308), the AMF (310) sends RatType as ‘NR’

[0180] FIG. 5 illustrates an exemplary flow diagram (500) of a method for a Protocol Data Unit (PDU) session establishment procedure for the NR RedCap UE, in accordance with an embodiment of the present disclosure.

[0181] In an embodiment, the flow diagram (500) depicts the interactions between various network entities, including the UE (104), the gNodeB (302), the AMF (310), the SMF (308), the PCF (314), the UDM (316), the UPF (304), a CHF (326) and a DN (306).

[0182] The PDU session establishment procedure begins at step 502, where the UE (104) sends a PDU Session Establishment Request to the gNodeB (302). This request is forwarded by the gNodeB (302) to the AMF (310), which begins the PDU session management process.

[0183] At step 504, the AMF (310) selects the SMF (308) and sends a Nsmf PDUSession CreateSMContext Request to the SMF (308), with the RAT type set as "NR”. In response, at step 506, the SMF (308) retrieves subscription data by initiating a Nudm SDM Get request to the UDM (316). To ensure dynamic updates, the SMF (308) also performs a Nudm SDM Subscribe operation at step 508.

[0184] Further, at step 510, the SMF (308) sends respond to the AMF (310) with a Nsmf_PDUSession_Create SM context response message. This ensures the PDU session is established and authentication and authorization of the UE (104) with the set of secondary network function is completed. The SMF (308) selects the PCF (314) of policy creation and association.

[0185] Further, at step 512, the SMF (308) initiates policy association establishment by interacting with the PCF (314) using the SM Policy Association Establishment procedure. Simultaneously, at step 514, the SMF (308) selects the appropriate UPF (304) for data path management by sending an N4 Session Establishment Request to the UPF (304) to establish the data session with the RAT type set as "NR”.

[0186] At step 516, the UPF (304) responds with an N4 Session Establishment Response.

[0187] To handle charging requirements, at step 518, the SMF (308) initiates a converged charging procedure by sending a charging create request to the CHF (326) with the RAT type set as "NR”.

[0188] Following the policy, session, and charging configurations, at step 520, the SMF (308) communicates with Namf_communication_NlN2 Message Transfer to the AMF (310) to proceed with the session setup.

[0189] At step 522, the AMF (310) sends an N2 PDU Session Request (NAS message) to the gNodeB (302). Following this, the gNodeB (302) sends AN specific resource setup to the UE (104) which marks the acceptance of the PDU session establishment request at the RAN level at step 524.

[0190] Further, the gNodeB (302), responds the AMF (310) with an N2 PDU Session Response at step 526.

[0191] The gNodeB (302) completes the Access Network (AN)-specific resource setup for the session, allowing the UE (104) to transmit its first uplink data at step 528.

[0192] To synchronize the PDU session updates, at step 530, the AMF (310) sends an Nsmf PDUSession UpdateSMContext Request to the SMF (308). This triggers an N4 Session Modification Request to the UPF (304) at step 532. Once the UPF (304) confirms the modification via an N4 Session Modification Response at step 534, the SMF (308) registers the PDU session details with the UDM (316) by sending a Nudm_UECM Registration request at step 536 with the RAT type set as "NR".

[0193] At step 538, the UPF (304) sends its first downlink data to the UE (104), indicating successful data flow within the session.

[0194] Further, at step 540, the SMF (308) sends an Nsmf PDUSession UpdateSMContext Response to confirm the update to the AMF (310). The SMF (308) concludes the procedure by notifying the status to the AMF (310) through Nsmf_PDUSession_SMContextStatusNotify at step 542, followed by a policy modification request at step 544 to finalize the session configuration and an unsubscription request to unsubscribe the updates, at step 546.

[0195] In an overall aspect, for the PDU session establishment procedure, instead of sending RatType as ‘NR RedCap’ in nsmf-pduSession-createSmContext message to the SMF (308), the AMF (310) sends RatType as ‘NR’.

[0196] FIG. 6 illustrates an exemplary flow diagram (600) of a method for Xn handover procedure for the NR RedCap UE, in accordance with an embodiment of the present disclosure. FIG. 6 is explained in conjunction with FIGs 1, 2, 3, 4 and 5.

[0197] The flow diagram (600) depicts interactions between various network entities, including the UE (104), a source eNB (Src_Ng_eNodeB, 602), a target gNB (Tar gNB, 604), the AMF (310), the SMF (308), and the UPF (304).

[0198] At step 606, the source eNodeB (602) initiates the handover preparation process by sending an RRC Connection Reconfiguration (Handover Command) to the UE (104).

[0199] The UE (104) responds by completing the reconfiguration process and sends an RRC Reconfiguration Complete (Handover Confirm) message back to the target gNB (604) at step (608).

[0200] At step 610, the target gNB (604) sends an N2 Path Switch Request message to the AMF (310). This message includes an indication that the UE (104) is a RedCap device (RAT Type = NR RedCap).

[0201] Upon receiving the Path Switch Request, the AMF (310) modifies the RAT type associated with the UE (104) from “NR RedCap” to “NR”. At step 612, the AMF (310) sends an Nsmf_PDUSession_UpdateSMContext request to the SMF (308), carrying the modified RAT type (RAT Type = NR). This ensures seamless compatibility with downstream network functions.

[0202] At step 614, the SMF (308) forwards an N4 Session Modification Request to the UPF (304). In this step, the SMF (308) transfers the RAT type as NR towards the UPF (304).

[0203] At step 616, the SMF (308) completes the handover session update and acknowledges the session changes and the N3 interface end marker is sent to release resources between the source gNB (602) and the UPF (304).

[0204] At step 618, the source gNB (602) further sent N3 end marker to the target gNB 604 to release resources of the UE (104).

[0205] At step 620, the AMF (310) sends an N2 Path Switch Request Ack to the target gNB (604), confirming the successful switch of the UE (104) to the target gNB (604).

[0206] Finally, at step 622, the target gNB (604) releases resources associated with the UE (104) towards the source eNB (602), completing the Xn handover procedure.

[0207] In an overall aspect, for the Xn handover procedure target gNB 604 sends Path Switch Request to the AMF (310) with RedCap indication. Thus, instead of sending RatType as ‘NR RedCap’ in nsmf-pduSession-updateSmContext message to the SMF (326), the AMF (310) sends RatType as ‘NR’.

[0208] FIG. 7 illustrates an exemplary flow diagram (700) of a method for N2 handover procedure, in accordance with an embodiment of the present disclosure. FIG. 7 is explained in conjunction with FIG. 7 is explained in conjunction with the FIGs, 1, 2, 3, 4, 5, and 6.

[0209] The flow diagram (700) depicts interactions between various network entities, including the UE (104), a source gNodeB (Src_gNB, 702), the target gNodeB (Tar gNodeB, 704), the AMF (310), the SMF (308), and the UPF (304).

[0210] At step 706, the source gNodeB (702) identifies the need for a handover and sends a Handover Required message to the AMF (310). This message includes the UE’s radio capabilities, indicating that it is a RedCap device.

[0211] At step 708, the AMF (310) forwards the Handover Request to the target gNodeB (704), including the UE radio capabilities for RedCap support.

[0212] The target gNodeB (704) acknowledges the handover request by sending a Handover Acknowledge message to the AMF (310) at step 710. Thismessage includes the RedCap indication and confirms the handover preparation for the RedCap UE.

[0213] At step 712, the AMF (310) sends a Handover Command back to the source gNodeB (702) to notify the UE (104) of the handover process.

[0214] The UE (104) transitions to the target gNodeB (704) and establishes a new connection.

[0215] Following this, at step 714, the target gNodeB (704) sends a Handover Notify message to the AMF (310) to confirm that the handover is complete.

[0216] At step 716, the AMF (310) modifies the RAT type from “NR RedCap” to “NR” and sends an Nsmf_PDUSession_UpdateSMContext request to the SMF (308). This ensures compatibility with the SMF (308) and other network functions.

[0217] The SMF (308) processes the update and sends an N4 Session Modification request to the UPF (304) at step 718, indicating the updated session information with the modified RAT type.

[0218] At step 720, the SMF (308) sends an Nsmf PDUSession UpdateSMContext Response back to the AMF (310), confirming the successful update of the PDU session.

[0219] Once the handover is complete, the AMF (310) initiates the mobility registration procedure for the new AMF.

[0220] At step 722, the AMF (310) sends a UE Context Release Command to the source gNodeB (702), instructing it to release the UE’s context.

[0221] At step 724, the source gNodeB (602) completes the context release and sends a UE Context Release Command Complete message back to the AMF (310), concluding the handover procedure.

[0222] In an overall aspect, during N2 handover, the target gNB (704) sends Handover Request Acknowledgement in response to Handover Request message from the AMF (310). The target gNB (704) includes NR Redcap indication in this message. Thus, instead of sending RatType as ‘NR RedCap’ in nsmf-pduSession- updateSmContext message to the SMF (308), the AMF (310) sends RatType as ‘NR’.

[0223] FIG. 8 illustrates an exemplary flow diagram (800) of a method for performing an Evolved Packet System (EPS) to a 5G System (5GS) handover procedure, in accordance with an embodiment of the present disclosure. FIG. 8 is explained in conjunction with the FIGS. 1, 2, 3, 4, 5, 6 and 7.

[0224] The flow diagram (800) indicates the interactions between various network entities, including the UE (104), an eNodeB (802), a gNodeB (302), a Mobility Management Entity (MME) (804), the AMF (310), an SMF_GW_C (806), an UPF GW U (808), and a PCF PCRF (810).

[0225] At step 812, the eNodeB (802) determines the need for a handover and sends a Handover Required message to the MME (804). This message includes the UE's radio capabilities, indicating it is a RedCap device.

[0226] The MME (804) forwards the Forward Relocation Request to the AMF (310) at step 814, also including the UE's radio capabilities.

[0227] At step 816, the AMF (310) initiates the creation of a new PDU session by sending an Nsmf PDUSession CreateSMContext Request to the SMF GW C (806).

[0228] At step 818, the SMF_GW_C (806) interacts with the PCF PCRF (810) to initiate an SM policy association modification.

[0229] At step 820, the SMF_GW_C (806) interacts with the UPF_GW_U (808) to modify the N4 session, ensuring RedCap support during the handover process.

[0230] At step 822, the SMF GW C (806) responds to the AMF (310) with an Nsmf PDUSession CreateSMContext Response confirming the successful creation of the PDU session.

[0231] At step 824, the AMF (310) sends a Handover Request to the gNodeB (302), providing the necessary information, including the UE's radio capabilities.

[0232] At step 826, the gNodeB (302) acknowledges this request with a Handover Request Ack message, including the RedCap indication.

[0233] At step 828, the AMF (310) sends a Forward Relocation Response back to the MME (804), confirming the readiness of the handover at the gNodeB (302).

[0234] At step 830, DownLink (DL) data start flowing from the UPF GW U (808) to the eNodeB (802). Simultaneously, at step 832, the eNodeB (802) continues forwarding the DL data to the gNodeB (304) to ensure a seamless transition.

[0235] At step 834, the MME (804) sends a Handover Command to the eNodeB (802).

[0236] At step 836, the eNodeB (802) sends an RRC Connection reconfiguration message (Handover Command) to the UE (104).

[0237] At step 838, the UE (104) completes the handover and sends an RRC Handover Complete message to the gNodeB (302).

[0238] At steps 840 and 842, the gNodeB (302) starts handling both DownLink (DL) and UpLink (UL) data transmission for the UE (104).

[0239] At step 844, the gNodeB (302) sends the UL data to the UPF GW U (808).

[0240] At step 846, the gNodeB (302) sends Handover Notify message to the AMF (310), indicating that the handover has been completed successfully.

[0241] At step 848, the AMF (310) sends a Forward Relocation Complete Notification to the MME (804), confirming the relocation process.

[0242] At step 850, the MME (804) sends a Forward Relocation Complete Notification acknowledgment to the AMF (310), acknowledging the completion of the relocation process.

[0243] At step 852, the AMF (310) modifies the RAT type from “NR RedCap” to “NR” and sends an Nsmf_PDUSession_UpdateSMContext Request to the SMF GW C (806).

[0244] At step 854, the SMF GW C (806) processes the request and sends an N4 Session Modification request to the UPF GW U (808), ensuring the updated session information reflects the correct RAT type.

[0245] At step 856, after receiving the N4 Session Modification request to the UPF GW U (808), it sends an End marker to finalize the handover by signaling the eNodeB (802).

[0246] At step 858, the End Marker is sent from the eNodeB (802) to the gNodeB (302), indicating that no more data packets will be forwarded from the eNodeB to the gNodeB. Simultaneously, the End Marker triggers the release of any remaining data path resources in the EPS (Evolved Packet System) domain to ensure a clean transition to the 5GS (5G System).

[0247] At steps 860 and 862, the gNodeB (302) confirms the receipt of the End Marker and resumes both downlink (DL) and uplink (UL) data handling for the UE (104).

[0248] At step 864, the SMF GW C (806) initiates SM policy association modifications, in collaboration with the PCF PCRF (810), to align with 5G standards and policies for the UE (104).

[0249] At step 866, the AMF (310) receives the final Nsmf PDUSession UpdateSMContext Response from the SMF GW C (806), confirming that the handover and all associated session updates have been completed.

[0250] Further, the mobility registration procedure is implemented between the UE (104) and the AMF (310). After the mobility registration procedure, the resource release process is done by MME (804) in EPS.

[0251] In an overall aspect, during the EPS to the 5GS handover call flow, the gNB (302) sends Handover Request Acknowledgement in response to Handover Request message from the AMF (310). The gNB (302) includes NR Redcap indication in this message. Thus, instead of sending RatType as ‘NR RedCap’ in nsmf- pduSession-updateSmContext message to the SMF GW C (806), the AMF (310) sends RatType as ‘NR’

[0252] FIG. 9 illustrates a method (900) flow diagram for the one or more network procedures for RedCap devices in the network 106, in accordance with an embodiment of the present disclosure. FIG. 5 is explained in conjunction with FIGS.l, and 2.

[0253] At step 902, the method 900 includes receiving, by the primary network function, at least one message from at least one network node. In an aspect, the primarynetwork function is the AMF. In an aspect, the at least one message includes the first RAT type identifier indicating that the at least one UE (104) is the NR RedCap device.

[0254] At step 904, the method 900 includes modifying, by the primary network function, the RAT type associated with the at least one UE (104) from the first RAT type identifier to the second RAT type identifier based on the received at least one message, for communication with the set of network functions. The modification includes, applying, by the primary network function, the predefined RAT conversion rule, where the predefined RAT conversion rule maps the first RAT type identifier representing the NR RedCap to the second RAT type identifier representing the NR.

[0255] At step 906, the method 900 includes transmitting, by the primary network function, the one or more messages comprising the modified RAT type to at least one of the set of secondary network functions for performing the one or more network procedures. In an aspect, the one or more messages includes at least one of: the registration message, the policy create message, the session create message, and the session update message. In an aspect, the one or more network procedures are at least one of the registration procedure, the session establishment procedure, and the handover procedure. Thus, the method (900) ensures consistent propagation and interpretation of the modified RAT type across all involved network functions, thereby preventing procedure mismatches, erroneous capability evaluations, and unintended service fallback. By distributing the modified RAT type during key control-plane procedures, the primary network function guarantees that the secondary network functions execute their respective operations such as registration handling, policy derivation, session management, or mobility processing based on a uniform and updated RAT context. This enables accurate resource allocation, optimized mobility decisions, and seamless continuity of service for the UE (104), even under dynamic RAT conditions or network-triggered RAT adjustments.

[0256] In another exemplary embodiment, the system (108) for performing the one or more network procedures for the RedCap devices in the network (106) is described. The system (108) includes the receiving module (208) and the communication management module (210) at the primary network function, where the communication management module (210) is coupled to the receiving module (208). The receiving module (208) is configured to receive the at least one message from the at least one network node. The communication management module (210) is configured to modify the RAT type associated with the at least one UE (104) from the first RAT type identifier to the second RAT type identifier based on the received at least one message, for communication with the set of network functions. The communication management module (210) is further configured to transmit the one or more messages including the modified RAT type to the at least one of the set of secondary network functions for performing the one or more network procedures.

[0257] FIG. 10 illustrates an exemplary computer system 1000 in which or with which embodiments of the present disclosure may be implemented.

[0258] As shown in FIG. 10, the computer system 1000 may include an external storage device 1010, a bus 1020, a main memory 1030, a read-only memory 1040, a mass storage device 1050, a communication port 1060, and a processor 1070. A person skilled in the art will appreciate that the computer system 1000 may include more than one processor 1070 and communication ports 1060. The processor 1070 may include various modules associated with embodiments of the present disclosure.

[0259] In an embodiment, the communication port 1060 may be any of an RS- 232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fibre, a serial port, a parallel port, or other existing or future ports. The communication port 1060 may be chosen depending on the network 106, such as a Local Area Network (LAN), a Wide Area Network (WAN), or any network to which the computer system 1000 connects.

[0260] In an embodiment, the memory 1030 may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory 1040 may be any static storage device(s), e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor 1070.

[0261] In an embodiment, the mass storage device 1050 may be any current or future mass storage solution, which may be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).

[0262] In an embodiment, the bus 1020 communicatively couples the processor(s) 1070 with the other memory, storage, and communication blocks. The bus 1020 may be, e.g., a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 1070 to the computer system (1000).

[0263] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and cursor control device, may also be coupled to the bus 1020 to support direct operator interaction with the computer system 1000. Other operator and administrative interfaces may be provided through network connections connected through the communication port 1060. The components described above are meantonly to exemplify various possibilities. In no way should the aforementioned exemplary computer system 1000 limit the scope of the present disclosure.

[0264] In an exemplary embodiment, a method for performing one or more network procedures for Reduced Capability (RedCap) devices in a network is described. The method includes receiving, by a primary network function, at least one message from at least one network node. The method includes modifying, by the primary network function, a Radio Access Technology (RAT) type associated with at least one user equipment (UE) from a first RAT type identifier to a second RAT type identifier based on the received at least one message, for communication with a set of network functions. The method includes transmitting, by the primary network function, one or more messages including the modified RAT type to at least one of the set of secondary network functions for performing the one or more network procedures.

[0265] The present disclosure provides a technical advancement in enabling seamless handling of Reduced Capability (RedCap) devices within a Fifth Generation (5G) network while requiring enhancements only at an Access and Mobility Management Function (AMF). Traditional systems lack a mechanism for ensuring consistent processing of RedCap-specific Radio Access Technology (RAT) identifiers across multiple network functions (NFs). As a result, secondary NFs such as the Session Management Function (SMF), Policy Control Function (PCF), Unified Data Management (UDM), and others NFs may reject or misinterpret signaling carrying the ‘NR RedCap’ RAT type, which leads to registration failures, PDU session establishment issues, policy retrieval errors, or inconsistent procedural behaviour. The method overcomes these limitations by introducing an AMF-centric RAT adaptation mechanism that converts the RAT type from ‘NR RedCap’ to the standard ‘NR’ value prior to forwarding messages to secondary NFs, while retaining the RedCap indication internally for device-specific processing. This ensures that one or more network procedures including registration, policy control, session establishment, and mobility handling are executed without requiring changes to secondary network functions. The methods maintains complete interoperability with existing 5G core implementations, reduces deployment and upgrade complexity, and enables RedCap device support through isolated modifications at the AMF alone.

[0266] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

[0267] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosuremay be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0268] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter to be implemented merely as illustrative of the disclosure and not as limitation.ADVANCEMENTS OF THE PRESENT DISCLOSURE

[0269] The present disclosure described herein above has several technical advantages as follows:

[0270] The present disclosure provides a mechanism for supporting one or more Reduced Capability (RedCap) devices in a Fifth Generation (5G) network by implementing enhancements only at an Access and Mobility Management Function (AMF).

[0271] The present disclosure may be capable of serving the one or more RedCap devices by making changes at the AMF alone and avoiding changes to other network functions (NFs) such as the SMF, PCF, SMSF, UDM, UPF, CHF, and the like, thereby reducing operational complexity and deployment time.

[0272] The present disclosure ensures interoperability between the one or more RedCap devices and existing network functions by converting the RAT type from “NR RedCap” to “NR” at the AMF side.

[0273] The present disclosure enables execution of one or more network procedures such as registration, policy control, mobility handling, and session establishment without requiring any procedural or interface modifications in other network functions (NFs) such as the SMF, PCF, SMSF, UDM, UPF, CHF, and the like, thereby ensuring seamless integration of the one or more RedCap devices into existing 5G network deployments.

Claims

CLAIMSWe claim:

1. A method (900) for performing one or more network procedures for Reduced Capability (RedCap) devices in a network (106), the method (900) comprising: receiving (902), by a primary network function, at least one message from at least one network node; modifying (904), by the primary network function, a Radio Access Technology (RAT) type associated with at least one user equipment (UE) (104) from a first RAT type identifier to a second RAT type identifier based on the received at least one message, for communication with a set of network functions; and transmitting (906), by the primary network function, one or more messages comprising the modified RAT type to at least one of the set of secondary network functions for performing the one or more network procedures.

2. The method (900) as claimed in claim 1, wherein the one or more network procedures are at least one of a registration procedure, a session establishment procedure, and a handover procedure.

3. The method (900) as claimed in claim 1, wherein the primary network function is an Access and Mobility Management Function (AMF).

4. The method (900) as claimed in claim 1, wherein modifying the RAT type associated with the at least one UE (104) comprising: applying, by the primary network function, a predefined RAT conversion rule, wherein the predefined RAT conversion rule maps the first RAT type identifier representing an NR RedCap to the second RAT type identifier representing an NR.

5. The method (900) as claimed in claim 1, wherein the one or more messages comprises at least one of: a registration message, a policy create message, a session create message, and a session update message.

6. The method (900) as claimed in claim 1, wherein the at least one message comprise the first RAT type identifier indicating that the at least one UE (104) is a New Radio (NR) RedCap device.

7. A system (108) for performing one or more network procedures for Reduced Capability (RedCap) devices in a network, the system (108) comprising: a receiving module (208) and a communication management module (210) at a primary network function, wherein the communication management module (210) is coupled to the receiving module (208); wherein the receiving module (208) is configured to receive at least one message from at least one network node; wherein the communication management module (210) is configured to: modify a Radio Access Technology (RAT) type associated with at least one User Equipment (UE) (104) from a first RAT type identifier to a second RAT type identifier based on the received at least one message, for communication with a set of network functions; and transmit one or more messages comprising the modified RAT type to at least one of the set of secondary network functions for performing the one or more network procedures.

8. The system (108) as claimed in claim 7, wherein the one or more network procedures are at least one of a registration procedure, a session establishment procedure, and a handover procedure.

9. The system (108) as claimed in claim 7, wherein the primary network function is an Access and Mobility Management Function (AMF).

10. The system (108) as claimed in claim 7, wherein to modify the RAT type associated with the at least one UE (104), the communication management module (210) is configured to: apply a predefined RAT conversion rule, wherein the predefined RAT conversion rule maps the first RAT type identifier representing an NR RedCap to the second RAT type identifier representing an NR.

11. The system (108) as claimed in claim 6, wherein the one or more messages comprises at least one of: a registration message, a policy create message, a session create message, and a session update message.

12. The system (108) as claimed in claim 7, wherein the at least one message includes the first RAT type identifier indicating that the at least one UE (104) is a New Radio (NR) RedCap device13. A computer program product comprising a non -transitory computer-readable medium comprising instructions that, when executed by one or moreprocessors, cause the one or more processors to execute a method (900) for performing one or more network procedures for Reduced Capability (RedCap) devices in a network, the method (900) comprising: receiving (902), by a primary network function, at least one message from at least one network node; modifying (904), by the primary network function, a Radio Access Technology (RAT) type associated with at least one user equipment (UE) (104) from a first RAT type identifier to a second RAT type identifier based on the received at least one message, for communication with a set of network functions; and transmitting (906), by the primary network function, one or more messages comprising the modified RAT type to at least one of the set of secondary network functions for performing the one or more network procedures.

Images