FORM 2
THE PATENTS ACT, 1970 (39 of 1970) THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10; rule 13)
TITLE OF THE INVENTION
SYSTEM AND METHOD FOR DYNAMIC SERVICE PROVISIONING IN A NETWORK
APPLICANT
JIO PLATFORMS LIMITED
of Office-101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad -
380006, Gujarat, India; Nationality : India
The following specification particularly describes
the invention and the manner in which
it is to be performed

RESERVATION 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
5 dress protection, belonging to Jio Platforms Limited (JPL) 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
10 reserved by the owner.
FIELD OF INVENTION
[0002] The present disclosure generally relates to systems and methods for
unified orchestration in an application programming interface (API) driven network
15 automation using a software-defined networking (SDN) controller. More
particularly, the present disclosure relates to a system and a method for dynamic service provisioning in a network.
BACKGROUND OF THE INVENTION
20 [0003] The following description of the 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 is used only to enhance the understanding of the reader with respect to the present disclosure,
25 and not as admission of the prior art.
[0004] Wireless communication technology has rapidly evolved over the
past few decades. The first generation of wireless communication technology was analog technology that offered only voice services. Further, when the second-generation (2G) technology was introduced, text messaging and data services
30 became possible. The 3G technology marked the introduction of high-speed
internet access, mobile video calling, and location-based services. The fourth
2

generation (4G) technology revolutionized the wireless communication with faster
data speeds, improved network coverage, and security. Fifth-generation (5G) and
advanced-generation technology are being deployed, with even faster data speeds,
low latency, and the ability to connect multiple devices simultaneously.
5 [0005] As mobile networks continue to grow, users are increasingly
concerned about the quality and performance of their network connections. The 5G networks are upgrading their software and hardware functionalities to transform the facilities provided to consumers. However, operators are no longer buying proprietary hardware from vendors but are building their data centres to host the
10 applications using a multi-vendor ecosystem. Current deployments include data
centres deployed at various geographical locations. However, there is a need for
automating and orchestrating the end-to-end lifecycle of infrastructure at scale for
managing and optimizing complex software environments effectively.
[0006] There is, therefore, a need in the art to provide a system and a method
15 that can mitigate the problems associated with the prior arts and provide a
centralized management, automation, and control across diverse platforms and services in an organization to improve operational efficiency and enhance agility.
OBJECTS OF THE INVENTION
20 [0007] It is an object of the present disclosure to provide a system and a
method for providing dynamic runtime orchestration in a network.
[0008] It is an object of the present disclosure to provide a system and a
method to provide cross domain service provisioning in the network.
[0009] It is an object of the present disclosure to provide a system and a
25 method to provide dynamic change of schema of an application programming
interface (API) by runtime structure modification of the API definitions.
SUMMARY
[0010] In an exemplary embodiment, the present invention discloses a
30 method for performing a dynamic service provisioning in a network. The method
comprises receiving a request for a network service from a user equipment (UE).
3

The method comprises extracting one or more attributes associated with the
received request. The method comprises determining one or more application
programming interface(s) (APIs) required for implementing the network service.
The method comprises performing a change in a structure of the one or more APIs
5 based on the one or more attributes. The method comprises triggering the one or
more APIs for providing the dynamic service provisioning in the network.
[0011] In an embodiment, the change in the structure of the one or more
APIs is performed by a data modelling framework (DMF).
[0012] In an embodiment, the DMF forms at least one key value pair each
10 for a Java script object notation (JSON) format and an extensible mark-up language
(XML) format associated with of the one or more APIs.
[0013] In an embodiment, the DMF converts the JSON format, the XML
format and the at least one key value pair into a flat structure.
[0014] In an embodiment, the one or more APIs required for implementing
15 the network service is determined by an abstraction layer of an orchestrator platform
generated for implementing the received request.
[0015] In an embodiment, the one or more attributes are related to at least
one API associated with the received request.
[0016] In an embodiment, the received request includes a cross domain
20 service request.
[0017] In an embodiment, the cross domain service request comprises at
least one of an edge device request, a customer premise equipment request, an
enterprise request, and an optical network request.
[0018] In an embodiment, the one or more attributes associated with the
25 received request include at least one of a request header, a query string, and a
request body.
[0019] In an exemplary embodiment, the present invention discloses a
system for performing a dynamic service provisioning in a network. The system
comprising a receiving unit configured to receive a request for a network service
30 from a user equipment (UE), a database configured to store the received request and
a processing unit coupled to the receiving unit and the database. The processing
4

unit configured to receive the request from the database. The processing unit
configured to extract one or more attributes associated with the received request.
The processing unit configured to determine one or more application programming
interface(s) (APIs) required for implementing the network service. The processing
5 unit configured to perform a change in a structure of the one or more APIs based
on the one or more attributes. The processing unit configured to trigger the one or
more APIs for providing the dynamic service provisioning in the network.
[0020] In an embodiment, the change in the structure of the one or more
APIs is performed by a data modelling framework (DMF).
10 [0021] In an embodiment, the DMF forms at least one key value pair each
for a Java script object notation (JSON) format and an extensible mark-up language
(XML) format associated with of the one or more APIs.
[0022] In an embodiment, the DMF converts the JSON format, the XML
format and the at least one key value pair into a flat structure.
15 [0023] In an embodiment, the one or more APIs required for implementing
the network service is determined by an abstraction layer of an orchestrator platform
generated for implementing the received request.
[0024] In an embodiment, the one or more attributes are related to at least
one API associated with the received request.
20 [0025] In an embodiment, the received request includes a cross domain
service request.
[0026] In an embodiment, the cross domain service request comprises at
least one of an edge device request, a customer premise equipment request, an
enterprise request, and an optical network request.
25 [0027] In an embodiment, the one or more attributes associated with the
received request include at least one of a request header, a query string, and a
request body.
[0028] In an exemplary embodiment, the present invention discloses a user
equipment (UE) communicatively coupled with a network. The coupling comprises
30 steps of receiving, by the network, a connection request from the UE, sending, by
the network, an acknowledgment of the connection request to the UE and
5

transmitting a plurality of signals in response to the connection request. A dynamic
service provisioning in the network is performed by a method comprises receiving
a request for a network service from the UE. The method comprising extracting
one or more attributes associated with the received request. The method comprises
5 determining one or more application programming interface(s) (APIs) required for
implementing the network service. The method comprises performing a change in
a structure of the one or more APIs based on the one or more attributes. The method
comprises triggering the one or more APIs for providing the dynamic service
provisioning in the network.
10 [0029] 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.
BRIEF DESCRIPTION OF DRAWINGS
15 [0030] The accompanying drawings, which are incorporated herein, and
constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the
20 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 the disclosure of electrical components, electronic components, or circuitry commonly used to implement such components.
25 [0031] FIG. 1 illustrates an example network architecture for implementing
a proposed system, in accordance with an embodiment of the present disclosure.
[0032] FIG. 2 illustrates an example block diagram of a proposed system,
in accordance with an embodiment of the present disclosure.
[0033] FIG. 3 illustrates an example block diagram of an architecture
30 realised through a representational state transfer (REST) native approach, in
accordance with embodiments of the present disclosure.
6

[0034] FIG. 4 illustrates an example block diagram of a software defined
networking (SDN) orchestrator platform, in accordance with embodiments of the
present disclosure.
[0035] FIG. 5 illustrates an example block diagram of runtime change in an
5 application programming interface (API) definition, in accordance with
embodiments of the present disclosure.
[0036] FIG. 6A illustrates an example structure of the API definition, in
accordance with embodiments of the present disclosure.
[0037] FIG. 6B illustrates an example block diagram of configuration
10 details of a query string to be sent in a hypertext transfer protocol request (HTTP),
in accordance with embodiments of the present disclosure.
[0038] FIG. 7 illustrates an example block diagram representing details of
the header, in accordance with embodiments of the present disclosure.
[0039] FIG. 8 illustrates an example representation of a MAP categorizing
15 a Type-1 extensible mark-up language (XML) document, in accordance with
embodiments of the present disclosure.
[0040] FIG. 9 illustrates an example representation of a MAP categorizing
a Type-2 XML document, in accordance with embodiments of the present
disclosure.
20 [0041] FIG. 10 illustrates an example representation of a MAP categorizing
a Type-3 XML document, in accordance with embodiments of the present
disclosure.
[0042] FIG. 11 illustrates an example representation of a MAP decoding a
XML based payload event, in accordance with embodiments of the present
25 disclosure.
[0043] FIG. 12 illustrates an example representation of encoding an event,
in accordance with embodiments of the present disclosure.
[0044] FIG. 13 illustrates an example computer system in which or with
which the embodiments of the present disclosure may be implemented.
30 [0045] FIG. 14 illustrates an exemplary flow diagram for a method for
performing a dynamic service provisioning in a network.
7

[0046] The foregoing shall be more apparent from the following more
detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
5
100 – Network architecture
102-1, 102-2…102-N - A plurality of users
104-1, 104-2…104-N - A plurality of computing devices
106 - Network
10 108 - System
200 - Block diagram
202 - Receiving unit
204 - Memory
206 - Interfacing unit
15 208 - Processing unit
210 - Database
300 – Block Diagram
400 – Block Diagram
500 – Block Diagram
20 600A – Structure of the API definition
600B- Block Diagram
700 – Block Diagram
800 - An example representation of a MAP
900 - An example representation of a MAP
25 1000 - An example representation of a MAP
1100 - An example representation of a MAP
1200- An example representation of encoding an event
1300- A computer system
1310 - External storage device
30 1320 - Bus
1330 - Main memory
8

1340 - Read only memory
1350 - Mass storage device
1360 - Communication port(s)
1370 – Processor
5 1400- Flow Diagram
DETAILED DESCRIPTION
[0047] In the following description, for explanation, various specific details
are outlined in order to provide a thorough understanding of embodiments of the
10 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 all of the problems discussed above or might address only some of the problems discussed
15 above. Some of the problems discussed above might not be fully addressed by any
of the features described herein.
[0048] 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
20 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.
[0049] Specific details are given in the following description to provide a
25 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
30 circuits, processes, algorithms, structures, and techniques may be shown without
unnecessary detail to avoid obscuring the embodiments.
9

[0050] 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
5 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
10 function or the main function.
[0051] 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
15 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
20 “comprising” as an open transition word without precluding any additional or other
elements.
[0052] 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
25 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.
30 [0053] The terminology used herein is to describe particular embodiments
only and is not intended to be limiting the disclosure. As used herein, the singular
10

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
5 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.
[0054] Telecommunication network may include a collection of
10 interconnected devices such as routers, gateways, servers, access points, etc. These
devices perform different functions such as authentication, authorization, security, account management, network access services, resource allocation, etc. In some network, one or more features or functions of the network may be virtualized within a cloud computing environment. A cloud computing environment may include a
15 cluster of server devices that share resources (e.g., processing capacity, memory
capacity, server capacity, etc.) to host processes corresponding to virtualized network devices and functions. Virtualizing a network function in a cloud computing environment may provide several benefits, such as scalability, centralized monitoring and management, efficient use of network resources, and/or
20 other benefits.
[0055] A network function that is implemented by a physical device may be
referred to as a physical network function (PNF). By contrast, a network function that is implemented by a virtualized function or device may be referred to as a virtual network function (VNF). Network functions, whether implemented as PNFs,
25 VNFs, or a combination thereof, may provide network services. Examples of
network services may include network access and routing services, authentication and authorization services, quality of service (QoS) services, account management services, usage monitoring services, billing services, load balancing services, data storage services, and/or other types of services.
30 [0056] Implementing network functions and/or network services may
involve application program interfaces (APIs) that enable the functions and/or
11

services to communicate and otherwise interact with one another. An API may
include computer code that gives applications, functions, or users access to certain
features of a system, without necessarily knowing many details about internal
system architectures, structures, protocols used, etc. An API may provide an
5 interface for accessing the features. An API may enable incompatible systems to
communicate with one another. The number of APIs and their types of APIs may vary based on the network service being provided. Unless appropriate APIs are implemented, network functions and devices may not be capable of providing a particular network service.
10 [0057] The available techniques provide a static conversion of the APIs
based on the incoming service requests. Furthermore, the available systems generally handle a particular domain service request and thus the available systems fail to support multi domain requests. Thus, there is a need for an improved system and method that can handle all cross-domain requests without making any
15 disruption in the network.
[0058] The present disclosure aims to overcome the above-mentioned and
other existing problems in this field of technology by disclosing a system and a method that provides a dynamic service provisioning in a network by handling all domain requests coming from various sources (e.g., EDGE devices, customer
20 premise equipment, enterprise network, optical network) without making any
disruption in the network.
[0059] The various embodiments throughout the disclosure will be
explained in more detail with reference to FIGs. 1-14.
[0060] FIG. 1 illustrates an example network architecture (100) for
25 implementing a system (108), in accordance with an embodiment of the present
disclosure.
[0061] As illustrated in FIG. 1, one or more computing devices (104-1, 104-
2…104-N) may be connected to a system (108) through a network (106). A person of ordinary skill in the art will understand that the one or more computing devices
30 (104-1, 104-2…104-N) may be collectively referred as computing devices (104)
and individually referred to as a computing device (104). One or more users (102-
12

1, 102-2…102-N) may provide one or more requests to the system (108). A person
of ordinary skill in the art will understand that the one or more users (102-1, 102-
2…102-N) may be collectively referred to as users (102) and individually referred
as a user (102). Further, the computing devices (104) may also be referred as a user
5 equipment (UE) (104) or as UEs (104) throughout the disclosure.
[0062] In an embodiment, the computing device (104) may include, but not
be limited to, a mobile, a laptop, etc. Further, the computing device (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, audio aid, microphone, or keyboard.
10 Furthermore, the computing device (104) may include a mobile phone, smartphone,
virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, and a mainframe computer. Additionally, input devices for receiving input from the user (102) such as a touchpad, touch-enabled screen, electronic pen, and the like may be
15 used.
[0063] 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 a combination thereof, etc. one or more messages, packets, signals,
20 waves, voltage or current levels, some combination thereof, or so forth. The
network (106) may also include, by way of example but not limitation, one or more of 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),
25 a cable network, a cellular network, a satellite network, a fiber optic network, or
some combination thereof. The UE (104) may be communicatively coupled with the network (106). The communicatively coupling comprises of receiving, from the UE (104), a connection request by the network (106), sending an acknowledgment of the connection request to the UE (104) and transmitting a plurality of signals in
30 response to the connection request.
13

[0064] FIG. 2 illustrates an example block diagram (200) of a system (108),
in accordance with an embodiment of the present disclosure.
[0065] Referring to FIG. 2, in an embodiment, the system (108) may include
a receiving unit (202), a memory (204), an interfacing unit (206), a processing unit
5 (208), a database (210). The receiving unit (202) is configured to receive a request
for a network service from the UE (104), a database (210) configured for storing the received request and a processing unit (208) coupled to the receiving unit (202) and the database (210). The processing unit (208) is configured to receive the request from the database. The processing unit (208) is configured to extract one or
10 more attributes associated with the received request. The processing unit (208) is
configured to determine one or more APIs required for implementing the network service. The network services encompass a wide range of functionalities provided by network infrastructure to ensure connectivity, security, performance, and management of data communications. These services are essential for supporting
15 various applications, users, and devices within a network. In an aspect the network
service includes an internet lease line service (ILL). The processing unit (208) is configured to perform a change in a structure of the one or more APIs based on the one or more attributes. The structure of the one or more APIs defines how requests and responses are organized, how data is formatted, and the conventions used for
20 communication between clients and servers. The processing unit (208) is
configured to trigger the one or more APIs for providing the dynamic service provisioning in the network. The dynamic service provisioning is essential for modern networking environments for enabling organizations to efficiently manage resources, respond to changing demands, and deliver high-quality services. By
25 leveraging automation, scalability, and real-time monitoring, organizations can
achieve greater agility, cost savings, and improved performance, ultimately enhancing the overall user experience. In an aspect, the request typically involves several technical attributes that define the nature of the request, its structure, and how it should be processed by the server. The key technical attributes of an API
30 request may include a HTTP method, endpoint URL, headers, query parameters,
request body, response format etc.
14

[0066] The processing unit (208) 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 processing unit (208)
5 may be configured to fetch and execute computer-readable instructions stored in a
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 create or share data packets over a network service. The memory (204) may comprise any
10 non-transitory storage device including, for example, volatile memory such as
random-access memory (RAM), or non-volatile memory such as erasable
programmable read only memory (EPROM), flash memory, and the like.
[0067] In an embodiment, the interfacing unit (206) may comprise a variety
of interfaces, for example, interfaces for data input and output devices (I/O), storage
15 devices, and the like. The interfacing unit (206) may facilitate communication
through the system (108). The interfacing unit (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, processing unit (208) and a database (210).
20 [0068] In an embodiment, the processing unit (208) may be implemented as
a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing unit (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for
25 the processing unit (208) may be processor-executable instructions stored on a non-
transitory machine-readable storage medium and the hardware for the processing unit (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the
30 processing resource, implement the processing unit (208). In such examples, the
system may comprise the machine-readable storage medium storing the instructions
15

and the processing resource to execute the instructions, or the machine-readable
storage medium may be separate but accessible to the system and the processing
resource. In other examples, the processing unit (208) may be implemented by
electronic circuitry.
5 [0069] In an embodiment, the change in the structure of the one or more
APIs is performed by a data modelling framework (DMF). In an embodiment, the DMF forms at least one key value pair each for a Java script object notation (JSON) format and an extensible mark-up language (XML) format associated with of the one or more APIs. In an embodiment, the DMF converts the JSON format, the XML
10 format and the at least one key value pair into a flat structure. In the flat structure,
the localization data is represented as a collection of key-value pairs within the JSON file, where each key represents a message identifier and the value a corresponding translation. In an embodiment, the one or more APIs required for implementing the network service is determined by an abstraction layer of an
15 orchestrator platform generated for implementing the received request. The
orchestrator manages the coordination and execution of multiple services, tasks, or
workflows. The orchestrator performs workflow management, resource allocation,
service coordination, scaling and load balancing and error handling and recovery.
[0070] In an embodiment, the one or more attributes are related to at least
20 one API associated with the received request. In an embodiment, the received
request includes a cross domain service request. In an embodiment, the cross domain service request comprises at least one of an edge device request, a customer premise equipment request, an enterprise request, and an optical network request. The cross-domain service request involves a web application making a request to a
25 resource or service hosted on a different domain. In an embodiment, the one or more
attributes associated with the received request include at least one of a request header, a query string, and a request body.
[0071] Although FIG. 2 shows exemplary components of the system (108),
in other embodiments, the system (108) may include fewer components, different
30 components, differently arranged components, or additional functional components
than depicted in FIG. 2. Additionally, or alternatively, one or more components of
16

the system (108) may perform functions described as being performed by one or more other components of the system (108).
[0072] FIG. 3 illustrates an example block diagram (300) of an architecture
realised through a representational state transfer (REST) native approach, in
5 accordance with embodiments of the present disclosure.
[0073] As illustrated in FIG. 3, in an embodiment, a platform for REST
native approach (300) may include the following. In an embodiment, a Platform External application programming interface (API) Gateway (PEAG) may be used by the system (108) as a master service orchestrator service that interfaces with the
10 platform or any operations support systems (OSS) systems in north bound and
network specific software-defined networking (SDN) controllers on south bound. In an embodiment, an Identity & Access Manager (IAM) may be used by the system (108) to manage access and authorization of users (102) and micro services. In an embodiment, a software-defined networking (SDN) orchestrator graphic user
15 interface (GUI) may be used by the system (108) for provisioning, creating
rules/workflows and queries and for visualizing output. providing centralized control and automation of network resources. The SDN orchestrators enable dynamic provisioning, configuration, and management of network services through a centralized software-based approach. In an embodiment, a Command Line
20 Interface (CLI) may be used by the system (108) as a Centralised Command Line
Interface. The CLI is a text-based user interface used to interact with software and operating systems. The CLI is different from graphical user interfaces (GUIs), which rely on visual indicators and mouse interactions. The CLI requires users to type commands into a console or terminal to perform tasks.
25 [0074] As illustrated in FIG. 3, in an embodiment, the REST native
approach (300) includes a CPE management platform (302) is a centralized system designed to monitor, configure, and manage CPE devices deployed at customer premises (304). The customer premises (304) includes Virtual Customer Premises Equipment (vCPE) and Universal Customer Premises Equipment (uCPE). The
30 vCPE are routers, firewalls, and switches, into software-based solutions that run on
commodity hardware or virtual machines. The uCPE refers to a hardware platform
17

that consolidates multiple networking functions into a single device deployed at the
customer premises (304). In an embodiment, an Operations, Administration and
Management (OAM) (306) may be used by the system (108) to manage the
Registration/De registration of the microservices and manage the traffic in the
5 network. A network manager (308) manages the operation of the network (106).
The IP network and data centre (310) comprises a plurality of virtual network functions (vNFs). An optical software-defined networking controller (SDNC) (312) manages and orchestrates resources of the optical network (314) in a programmable and automated manner. The provisioning manager (316) is responsible for
10 overseeing the process of service provisioning in the network (106). The
Northbound Interface (NBI) systems (318) enable the external higher-level applications to interact with the microservices. In an embodiment, the various microservices (320) include an Edge Load Balancer (ELB) microservice, and the API gateway microservice. The existing Northbound applications may see a single
15 pane of glass for network API exposure for Software-Defined Wide Area Network
(SD-WAN) with no CLI or sockets required. The SDN underlay vCPE, uCPE or Transport Software-Defined Networking (T-SDN) service orchestration. In the SD-WAN architecture, vCPE/uCPE may work as the customer premises equipment. The vNFs such as firewall, WAN optimization, application and performance aware
20 routing, NAT etc. will be hosted on the CPE or in the datacentre based on the
customer requirements. The VNFs will be orchestrated through a platform.
[0075] FIG. 4 illustrates an example block diagram (400) of software
defined networking (SDN) orchestrator platform, in accordance with embodiments of the present disclosure.
25 [0076] As illustrated in FIG. 4, in an embodiment, the SDN orchestrator
platform (400) includes the PEAG (402) that includes common components for vCPE management, telecommunications software defined networking (TSDN) management and core network management. In an embodiment, the SDN orchestrator platform (400) includes the ELB (404), the OAM (406), the CLI (408)
30 and the IAM (410), a user interface (UI) (412). The UI (412) enables interaction
with platform components (414), a database (416), the external systems (418) such
18

as the NBI and operations support systems (OSS) and business support systems
(BSS). The UI (412) enables interaction with the Software-Defined Networking
Controller (SDN-C) (420). In an embodiment, PEAG may be used by the system
(108) as a master service orchestrator service that interfaces with the platform or
5 any operations support systems (OSS) systems in north bound and network specific
software-defined networking (SDN) controllers on south bound. In an embodiment,
the IAM may be used by the system (108) to manage access and authorization of
users (102) and micro services.
[0077] FIG. 5 illustrates an example block diagram (500) of runtime change
10 in an application programming interface (API) definition, in accordance with
embodiments of the present disclosure.
[0078] As illustrated in FIG. 5, in an embodiment, with the abstraction
layer, the end user will not know what the API calls to be made are, and this abstraction layer plays a vital role, and makes multiple API calls internally based
15 on a single incoming request from the end user (north bound system).
[0079] In an exemplary embodiment, a request for an internet leased line
(ILL) service may be made by the end user to the orchestrator. This request comes in a single API. However, the system (108) by use of the abstraction layer knows the required plurality of API requests to be made to complete the ILL service
20 provision. Hence, the end user may remain isolated from the robust system. The
mapping of APIs to be triggered, based on request may be pre-configured and stored. Hence, the API handles all domain requests (EDGE Devices (Customer premise equipment’s)/Enterprise/Optical network/Underlay Core Internet Protocol (IP) network).
25 [0080] As illustrated in FIG. 5, in an embodiment, the system (108) may
generate parameter lists with query string parameters to be sent in the HTTP request for a particular event. The SDN orchestrator platform system manages the services and sub-services in a transparent manner to the northbound OSS. The APIs being exposed towards the OSS would cater to product ordering and fulfilment. The
30 resource facing services are abstracted out. The incoming request is received and
after the abstraction (502) by the abstraction layer, the technical attributes of the
19

request are filtered for offering and fulfilment of specific attributes. The abstraction
provides the segregation and enrichment of the downstream requests with technical
attributes. The request is moved to the SDN-C (504) which provides a response
essential for the service provision. The response may be saved in a database (506).
5 The abstraction layer prepares the SDN domain specific messages to communicate
to the appropriate SDN controller (504).
[0081] FIG. 6A illustrates an example structure (600A) of the API
definition, in accordance with embodiments of the present disclosure.
[0082] In an embodiment, structure (600A) of the API definition include
10 API context, query string, request header and request body. The request header may
include a plurality of attributes such as attribute 1, attribute 2 and attribute N. The SDN orchestrator platform supports change in the API definitions at run time to cater to dynamic needs of the network. The changes in the API definition are traced by tighter version control on the API contract. In an embodiment, the API definition
15 can be changed by changing the query string to provide additional parameters in the
API. In an embodiment, the API definition can be changed by adding/removing or by changing the parameters in the request header at run time. Further, a structure of the Java script object notation (JSON) body in the request and response is configurable in an excel sheet which is templatized to support Yet Another Next
20 Generation (YANG) models. The YANG models are used to define the structure,
hierarchy, and semantics of data exchanged between network management systems and network devices.
[0083] FIG. 6B illustrates an example block diagram (600B) of
configuration details of a query string to be sent in a hypertext transfer protocol
25 request (HTTP), in accordance with embodiments of the present disclosure.
[0084] As illustrated in FIG. 6B, in an embodiment, the system (108) may
generate the query parameters with various parameter fields such as KEY, H/B/Q and FIELD NAME that need to be sent in the HTTP request for a particular event. The KEY parameter is kept as key of the query string. The header/body/query string
30 (H/B/Q) parameter specifies from where the value of query string will be fetched
i.e., filed name is received at PEAG in which HTTP parameter. The FIELD NAME
20

defines the name of field whose value will be sent in query string and is present in
either header/query/body. For e.g. For generating query string:
‘?neid=value&deviceid=deviceValue’ the parameters may contain
neid=B#endpoint_devicesne_id, deviceid=H#endpoint_devicesne_id.
5 [0085] FIG. 7 illustrates an example block diagram (700) representing
details of the header, in accordance with embodiments of the present disclosure.
[0086] As illustrated in FIG. 7, in an embodiment, the system (108) may
use the header for a particular event. As illustrated in FIG. 7, in an embodiment, the system (108) may generate the query parameters with various parameter fields such
10 as KEY, H/B/Q and FIELD NAME. The parameter lists the headers that need to be
sent in the HTTP request for the particular event. The KEY parameter is kept as key of the header. The header/body/query string (H/B/Q) parameter specifies the from where the value of the header will be fetched i.e., filed name is received at PEAG in which HTTP parameter. The FIELD NAME defines the name of the field whose
15 value will be sent in the header and is present in either header/query/body. For e.g.
for generating the header, the parameter may contain
deviceid=H#endpoint_devicesne_id.
[0087] FIG. 8 illustrates an example representation (800) of a MAP
categorizing a Type-1 extensible mark-up language (XML) document, in
20 accordance with embodiments of the present disclosure.
[0088] As illustrated in FIG. 8, in an embodiment, the system (108) may
convert a tree structure into flat tabular format (flat structure) to fit into a database (DB). The keys of the converted table are the properties of various XML nodes which may be used to query record(s). The system (108) may convert the tree
25 structure into instance(s) of MAP. Each property is made as a search criterion to
fulfil any search requirement. The specific properties (keys) are called as the ‘search criteria’.
[0089] Further, an XML document may be roughly categorized in following
3 types:
30 • TYPE-1: The XML document will be decoded and whole data go
into a single MAP.
21

• TYPE-2: The XML document will be decoded, and fragments will
be created on the basis of a middle level XML node. Each
fragment will be put into MAP instances.
• TYPE-3: The XML document will be decoded, and fragments will
5 be created at leaf XML node level, keeping all the properties of
parent node(s). Each fragment will be put into MAP instances.
In an aspect, the whole document data will be put into a single MAP.
[0090] FIG. 9 illustrates an example representation (900) of a MAP
categorizing a Type-2 XML document, in accordance with embodiments of the
10 present disclosure.
[0091] As illustrated in FIG. 9, in an embodiment, the system (108) may
convert a whole document into a single MAP based on various key search criterions.
[0092] FIG. 10 illustrates an example representation (1000) of a MAP
categorizing a Type-3 XML document, in accordance with embodiments of the
15 present disclosure.
[0093] As illustrated in FIG. 10, in an embodiment, the system (108) may
categorize the XML document with various MAP instances.
[0094] FIG. 11 illustrates an example representation (1100) of a MAP
decoding a XML based payload event, in accordance with embodiments of the
20 present disclosure.
[0095] As illustrated in FIG. 11, in an embodiment, the system (108) may
decode an XML payload event. Decoding an XML based payload event
Describing the entry: A>aAttr#B>bAttr#C>cAttr1=cAttr2
# : Every tag property is separate by ‘#’
25 > : Delimiter for tag name and its attributes
, : Delimiter for various attributes of a tag
= : Used when values of 2 attributes of a tag are mapped into the MAP as key-value.
LHS will be the key.
DATE/INTEGER/LONG: The value of these entries is treated with special
30 conversion of data type before storing into MAP. E.g., suppose there is an entry in
22

INTEGER column –age and the value comes in XML document as ‘age = “29”’. The decoder will convert into integer 29 and put into MAP.
Document Hierarchy: The distinct path(s) of XML document separated by ‘,’.
Describing the entry: A-1>B<-1>C-*> : Nodes are delimited by ‘>’. LHS will be
5 the parent node.
-: Delimiter between tag name and its multiplicity in a single instance of MAP. The RHS will be ‘1’ OR ‘*’.
RHS is ‘1’: Data of exactly 1 instance of this node will be stored as fragment/MAP. RHS is ‘*’: Data of all instances of these nodes will be stored in a fragment/MAP
10 at this level.
<: Indication of bifurcation of data path in a distinct path. The data of this node will be copied to a new instance of MAP and then this instance may be forwarded to store data of next lower level node(s). Here we have taken example of TYPE-2 XML document, where decision making (of bifurcation) is done at some level
15 between root node and leaf node (here at level B). There may be multiple
occurrences of ‘<’in a distinct path, whenever bifurcation is required in a data path. Encoder Type: For future use. Currently supported is TYPE1.
Decoder Type: The XML category type. Possible values may be X(=1), Y(=2), OR Z(=3). These values are used to identify when to complete the fragment and store
20 into the database. The Index Name/Type: The database index name and type for
storing the document/fragment.
[0096] FIG. 12 illustrates an example representation (1200) of encoding an
event, in accordance with embodiments of the present disclosure.
[0097] In an embodiment, a data modelling framework (DMF), has the
25 functionality to fetch appropriate data from the database and then encode it to create
a complete HTTP event. The DMF first encodes the payload as XML and uses the graph nodes that are stored in the memory to decide the schema of the payload. The DMF construct the whole event by traversing the graph (payload node). The DMF has the functionality to fetch appropriate data from the database and then encode it
30 to create a complete HTTP event. First it encodes the payload as XML and it uses
23

the graph nodes, stored in the memory to decide the schema the payload and then construct the whole event by traversing the graph.
[0098] As illustrated in FIG. 12, in an embodiment, the system (108) may
encode an XML based payload event based on the event sub-types.
5 [0099] FIG. 13 illustrates an example computer system (1300) in which or
with which the embodiments of the present disclosure may be implemented.
[00100] As shown in FIG. 13, the computer system (1300) may include an
external storage device (1310), a bus (1320), a main memory (1330), a read-only memory (1340), a mass storage device (1350), a communication port(s) (1360), and
10 a processor (1370). A person skilled in the art will appreciate that the computer
system (1300) may include more than one processor and communication ports. The processor (1370) may include various modules associated with embodiments of the present disclosure. The communication port(s) (1360) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a
15 Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or
other existing or future ports. The communication ports(s) (1360) may be chosen
depending on a network, such as a Local Area Network (LAN), Wide Area Network
(WAN), or any network to which the computer system (1300) connects.
[00101] In an embodiment, the main memory (1330) may be Random Access
20 Memory (RAM), or any other dynamic storage device commonly known in the art.
The read-only memory (1340) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor (1370). The mass storage device (1350) may be any current or future
25 mass storage solution, which can 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).
30 [00102] In an embodiment, the bus (1320) may communicatively couple the
processor(s) (1370) with the other memory, storage, and communication blocks.
24

The bus (1320) 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
5 processor (1370) to the computer system (1300).
[00103] In another embodiment, operator and administrative interfaces, e.g.,
a display, keyboard, and cursor control device may also be coupled to the bus (1320)
to support direct operator interaction with the computer system (1300). Other
operator and administrative interfaces can be provided through network
10 connections connected through the communication port(s) (1360). Components
described above are meant only to exemplify various possibilities. In no way should
the aforementioned exemplary computer system (1300) limit the scope of the
present disclosure.
[00104] FIG. 14 illustrates an exemplary flow diagram for a method (1400)
15 for performing a dynamic service provisioning in a network (106).
[00105] At 1402: The method (1400) comprising receiving a request for a
network service from a user equipment (UE) (104).
[00106] At 1404: The method (1400) comprising extracting one or more
attributes associated with the received request.
20 [00107] At 1406: The method (1400) comprising determining one or more
application programming interface(s) (APIs) required for implementing the
network service.
[00108] At 1408: The method (1400) comprising performing a change in a
structure of the one or more APIs based on the one or more attributes.
25 [00109] At 1410: The method (1400) comprising triggering the one or more
APIs for providing the dynamic service provisioning in the network.
[00110] In an embodiment, the change in the structure of the one or more
APIs is performed by a data modelling framework (DMF).
[00111] In an embodiment, the DMF forms at least one key value pair each
30 for a Java script object notation (JSON) format and an extensible mark-up language
(XML) format associated with of the one or more APIs.
25

[00112] In an embodiment, the DMF converts the JSON format, the XML
format and the at least one key value pair into a flat structure.
[00113] In an embodiment, the one or more APIs required for implementing
the network service is determined by an abstraction layer of an orchestrator platform
5 generated for implementing the received request.
[00114] In an embodiment, the one or more attributes are related to at least
one API associated with the received request.
[00115] In an embodiment, the received request includes a cross domain
service request.
10 [00116] In an embodiment, the cross domain service request comprises at
least one of an edge device request, a customer premise equipment request, an enterprise request, and an optical network request.
[00117] In an embodiment, the one or more attributes associated with the
received request include at least one of a request header, a query string, and a
15 request body.
[00118] In an exemplary embodiment, the present invention discloses a
system for performing a dynamic service provisioning in a network. The system comprising a receiving unit configured to receive a request for a network service from a user equipment (UE), a database configured to store the received request and
20 a processing unit coupled to the receiving unit and the database. The processing
unit configured to receive the request from the database. The processing unit configured to extract one or more attributes associated with the received request. The processing unit configured to determine one or more application programming interface(s) (APIs) required for implementing the network service. The processing
25 unit configured to perform a change in a structure of the one or more APIs based
on the one or more attributes. The processing unit configured to trigger the one or
more APIs for providing the dynamic service provisioning in the network.
[00119] In an exemplary embodiment, the present invention discloses a user
equipment (UE) communicatively coupled with a network. The coupling comprises
30 steps of receiving, by the network, a connection request from the UE, sending, by
the network, an acknowledgment of the connection request to the UE and
26

transmitting a plurality of signals in response to the connection request. A dynamic
service provisioning in the network is performed by a method that includes
receiving a request for a network service from the UE. The method includes
extracting one or more attributes associated with the received request. The method
5 includes determining one or more application programming interface(s) (APIs)
required for implementing the network service. The method includes performing a change in a structure of the one or more APIs based on the one or more attributes. The method includes triggering the one or more APIs for providing the dynamic service provisioning in the network.
10 [00120] 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
15 disclosure herein, whereby it is to be distinctly understood that the foregoing
descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.
ADVANTAGES OF THE INVENTION
20 [00121] The present disclosure provides a system and a method that handles
all cross domain requests across a network.
[00122] The present disclosure provides a system and a method where a
downtime may not be required in case of an application programming interface (API) change request due to a dynamic change in the API.
25 [00123] The present disclosure provides a system and a method where a
dynamic behaviour in a Data Modelling Framework (DMF) may be observed where a javascript object notation (JSON), extensible mark-up language (XML) format and key value pairs are used and converted into a flat structure.
30
27

WE CLAIM:
1. A method (1400) for performing a dynamic service provisioning in a network
(106), the method (1400) comprising:
5 receiving (1402) a request for a network service from a user
equipment (UE) (104);
extracting (1404) one or more attributes associated with the received request;
determining (1406) one or more application programming
10 interface(s) (APIs) required for implementing the network service;
performing (1408) a change in a structure of the one or more APIs based on the one or more attributes; and
triggering (1410) the one or more APIs for providing the dynamic service provisioning in the network (106). 15
2. The method (1400) as claimed in claim 1, wherein the change in the structure of
the one or more APIs is performed by a data modelling framework (DMF).
3. The method (1400) as claimed in claim 2, wherein the DMF forms at least one
20 key value pair each for a Java script object notation (JSON) format and an
extensible mark-up language (XML) format associated with of the one or more APIs.
4. The method (1400) as claimed in claim 3, wherein the DMF converts the JSON
25 format, the XML format and the at least one key value pair into a flat structure.
5. The method (1400) as claimed in claim 1, wherein the one or more APIs required
for implementing the network service is determined by an abstraction layer of an
orchestrator platform generated for implementing the received request.
30

6. The method (1400) as claimed in claim 1, wherein the one or more attributes are
related to at least one API associated with the received request.
7. The method (1400) as claimed in claim 1, wherein the received request includes
5 a cross domain service request.
8. The method (1400) as claimed in claim 7, wherein the cross domain service
request comprises at least one of an edge device request, a customer premise
equipment request, an enterprise request, and an optical network request.
10
9. The method (1400) as claimed in claim 1, wherein the one or more attributes
associated with the received request include at least one of a request header, a query
string, and a request body.
15 10. A system (108) for performing a dynamic service provisioning in a network
(106), the system (108) comprising:
a receiving unit (202) configured to:
receive a request for a network service from a user equipment
(UE) (104);
20 a database (210) configured to:
store the received request; and
a processing unit (208) coupled to the receiving unit (202) and the database (210) and is configured to:
receive the request from the database (210);
25 extract one or more attributes associated with the received request;
determine one or more application programming interface(s) (APIs) required for implementing the network service;
perform a change in a structure of the one or more APIs based on
the one or more attributes; and
30 trigger the one or more APIs for providing the dynamic service
provisioning in the network (106).

11. The system (108) as claimed in claim 10, wherein the change in the structure of the one or more APIs is performed by a data modelling framework (DMF).
5 12. The system (108) as claimed in claim 11, wherein the DMF forms at least one
key value pair each for a Java script object notation (JSON) format and an extensible mark-up language (XML) format associated with of the one or more APIs.
10 13. The system (108) as claimed in claim 12, wherein the DMF converts the JSON
format, the XML format and the at least one key value pair into a flat structure.
14. The system (108) as claimed in claim 10, wherein the one or more APIs required
for implementing the network service is determined by an abstraction layer of an
15 orchestrator platform generated for implementing the received request.
15. The system (108) as claimed in claim 10, the one or more attributes are related
to at least one API associated with the received request.
20 16. The system (108) as claimed in claim 10, wherein the received request includes
a cross domain service request.
17. The system (108) as claimed in claim 16, wherein the cross domain service
request includes at least one of an edge device request, a customer premise
25 equipment request, an enterprise request, and an optical network request.
18. The system (108) as claimed in claim 10, wherein the one or more attributes
associated with the received request include at least one of a request header, a query
string, and a request body.
30

19. A user equipment (UE) (104) communicatively coupled with a network (106),
the coupling comprises steps of:
receiving, by the network (106), a connection request from the UE
(104);
5 sending, by the network (106), an acknowledgment of the
connection request to the UE (104); and
transmitting a plurality of signals in response to the connection request, wherein a dynamic service provisioning in the network (106) is performed by a method as claimed in claim 1. 10
20. 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 (1400) for performing a
dynamic service provisioning in a network (106), the method (1400) comprising:
15 receiving (1402) a request for a network service from a user
equipment (UE) (104);
extracting (1404) one or more attributes associated with the received request;
determining (1406) one or more application programming
20 interface(s) (APIs) required for implementing the network service;
performing (1408) a change in a structure of the one or more APIs based on the one or more attributes; and
triggering (1410) the one or more APIs for providing the dynamic service provisioning in the network (106). 25
Dated this 03 day of June 2024
~Digitally signed~
Anandan S
REG.NO:IN/PA-1717
of De Penning & De Penning
Agent for the Applicants