WO2025224477A1 - Syntax-tree assisted code generation by large language models - Google Patents

Abstract

A computer-implemented method is provided performed by a system for generation of program code by a LLM. The method includes providing (400) at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; and requesting (402), based on a hierarchical use of a syntax of the protocol from the at least one trace, that a second node generate program code to check whether a machine received at least a first message in the at least one trace. The syntax includes respective message types in a plurality of message types. The method further includes generating (404) the program code in the LLM to implement a third node with a behavior seen in the at least one trace provided to the LLM. The method further includes providing (406) at least the program code to the third node to execute the program code.

Description

SYNTAX-TREE ASSISTED CODE GENERATION BY LARGE LANGUAGE MODELS

TECHNICAL FEATURES

[0001] The present disclosure is related to communication systems and more particularly to syntax-tree assisted code generation by large language models.

BACKGROUND

[0002] Currently available Large Language Models (“LLMs”) are multi-modal and enable conversation and output generation in many diverse types of languages, including human textual languages, images, and video. They can also assist in programming (e.g., a LLM can be used to produce a code fragment or even a complete implementation of a given function). LLMs can be trained in the digital domain (e.g., a byte-oriented Generative Pre-trained Transformer (“GPT”) that can converse in bytes can be trained to process digital music formats or predict the behavior of a CPU).

SUMMARY

[0003] Some embodiments provide a computer-implemented method is provided performed by a system for generation of program code by a large language model, LLM, to implement a protocol. The method includes providing, by a first node including a control program and an LLM library to a second node including the LLM, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication. The method further includes requesting, based on a hierarchical use if a syntax of the protocol from the at least one trace, that the second node generate program code to check whether a machine in the machine-to-machine communication received at least a first message from the plurality of messages in the at least one trace. The syntax includes respective message types in a plurality of message types. The method further includes generating the program code in the LLM of the second node to implement a third node with a behavior seen in the at least one trace provided to the LLM. The method further includes providing at least the program code to the third node to execute the program code.

[0004] Other embodiments provide a computer-implemented method performed by a first node including a control program and a LLM library for generation of program code. The method includes providing, to a second node including a LLM, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication. The method further includes requesting, based on a hierarchical use of a syntax of the protocol from the at least one trace in a form that can be processed by the LLM, that the second node generate program code to check whether a machine in the machine-to-machine communication received at least a first message in the at least one trace of the plurality of messages from the protocol.

[0005] Still other embodiments provide a computer-implemented method performed by a second node including a LLM, for generation of program code by the LLM to implement a protocol. The method includes receiving, from a first node based on a syntax of the protocol from the at least one trace that is in a form that the LLM can process, a request to generate a program code to check whether a machine in a machine-to-machine communication received at least a first message in at least one trace of a plurality of messages from the protocol. The method further includes generating the program code in the LLM to implement a third node with a behavior seen in the at least one trace. The program code includes at least one of a check for at least one received message and an instruction to send at least one new message based on the received message. The method further includes providing at least the program code to the first node.

[0006] Yet other embodiments provide a computer-implemented method performed by a third node for implementation of a protocol based on a program code generated by a LLM. The method includes receiving a program code from a first node to implement a system with a behavior seen in at least one trace of a plurality of messages from a protocol in a machine-to- machine communication. The method further includes executing at least the program code. [0007] Other embodiments provide a computer-implemented method performed by a system for generation of program code by a LLM to implement a protocol. The method includes accessing, by a control program, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication. The method further includes requesting, based on a hierarchical use if a syntax of the protocol from the at least one trace, that the LLM generate program code to check whether a machine in the machine-to-machine communication received at least a first message from the plurality of messages in the at least one trace. The syntax includes respective message types in a plurality of message types. The method further includes generating the program code in the LLM to implement a second node with a behavior seen in the at least one trace provided to the LLM. The method further includes providing, by the control program, at least the program code to the second node to execute at least the program code.

[0008] According to other embodiments, a system, a first node, a second node, a third node, a computer program, a computer program product, a host, a system, or a non-transitory computer-readable medium is provided to perform one of the above methods. [0009] Certain aspects of these embodiments may provide technical advantages. Various embodiments described herein include a process by which the LLM is more likely to remember specific angles and protocol fields, everything is checked, and new messages are constructed correctly, regardless of the data type of the fields in the messages.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings:

[0011] FIG. 1 is a block diagram illustrating an example of schematic diagram illustrating an example of a procedure for syntax-tree assisted code generation by large language models in accordance with some embodiments;

[0012] FIG. 2 is a block diagram illustrating an example of a system in which observations are used to define behavior of a webserver in accordance with some embodiments;

[0013] FIG. 3 is a block diagram illustrating an example of a system for representing input traces in symbolic form in accordance with some embodiments;

[0014] FIG. 4 is a flow chart illustrating an example of operations performed by a system in accordance with some embodiments;

[0015] FIG. 5 is a block diagram of a node in accordance with some embodiments;

[0016] FIG. 6 is a block diagram of a communication system in accordance with some embodiments;

[0017] FIG. 7 is a block diagram of a user equipment in accordance with some embodiments;

[0018] FIG. 8 is a block diagram of a network node in accordance with some embodiments;

[0019] FIG. 9 is a block diagram of a virtualization environment in accordance with some embodiments;

[0020] FIG. 10 is a diagram illustrating an example of protocol traces recorded from a system in accordance with some embodiments;

[0021] FIG. 11 is a diagram illustrating an example of a formal syntax of a protocol and its messages in accordance with some embodiments;

[0022] FIG. 12 is a diagram illustrating an example of running the result of code generation in accordance with some embodiments;

[0023] FIG. 13 is a diagram illustrating an example of generated code in accordance with some embodiments; [0024] FIG. 14 is a flow chart illustrating an example of operations performed by a first node in accordance with some embodiments;

[0025] FIG. 15 is a flow chart illustrating an example of operations performed by a second node in accordance with some embodiments;

[0026] FIG. 16 is a flow chart illustrating an example of operations performed by a third node in accordance with some embodiments;

[0027] FIG. 17 is a flow chart illustrating an example of operations performed by a system in accordance with some embodiments;

[0028] Figure 18 is a block diagram illustrating an example of a system deployment in accordance with some embodiments; and

[0029] FIG. 19 is a block diagram illustrating an example of another system deployment in accordance with some embodiments.

DETAILED DESCRIPTION

[0030] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.

[0031] There currently exist certain challenges. From a telecommunications perspective one potentially important new type of language would be the language of the machines: the protocols that are used to converse between different components in a mobile network, in the Internet, or in most other technical systems.

[0032] It is currently possible to converse with LLMs about protocol specifications and standards, as those are human language, but it is not possible to converse using these protocols natively (e.g., it is not currently possible to have the LLM send an ICMP message or understand a sequence of bytes sent to a socket).

[0033] Protocols can be considered language, and LLMs can be taught to speak that language. However, there are two primary questions that remain open: 1) What is the optimal way to enable the LLMs to have this capability? It is likely that the details on how to enable the LLMs to have this capability influences both how easy it is to achieve the capability, as well as how good of results can be obtained.

2) Once this capability to converse with LLMs using protocols in a native way is obtained, what are the applications that it could enable?

[0034] Embodiments herein may assume that there is a way to train LLMs to understand the patterns of protocol exchanges such that the LLM can be queried about them.

[0035] As with generative Al in general, it can be hard to foresee all possible applications ahead of time. But it seems like there is a lot of potential:

• Data generation (e.g., for testing);

• Explaining (e.g., for debugging);

• Acting as a node that understands the protocol (e.g., for quick prototyping);

• Performing tasks (e.g., “Send a DIAMETER message to terminate session S0001”);

• Generating software that implements a node supporting that protocol; and/or

• New ways to express tasks (e.g., for optimization).

[0036] FIG. 1 illustrates examples of operations associated with generative Al for syntaxtree assisted code generation by LLMs. Syntax-tree assisted code generation may include a hierarchical process as discussed further herein. Code may also be referred to herein as program code. In this example, a node 100 that includes a network protocol analyzer may obtain protocol traces and/or observations of a network interface and provide this information to a node 102 that includes a LLM and a control program. As discussed further herein, the control program can control inputs to the LLM, receive generated program code from the LLM, and provide at least the generated program code to node 104.Node 104 can use at least the program code 104 to execute at least the program code.

[0037] In this example, an LLM can be taught how to “behave” as a protocol entity (e.g., by predicting what would be an expected response in a given situation such as the next message to be sent given a sequence of previous messages). Embodiments herein may describe turning an LLM that is capable of understanding protocol behaviour patterns into something that can actually run code.

[0038] However, even if an LLM learns the patterns of a protocol, in order to use the LLM for any specific task, each step takes a large amount of time (e.g., just to react to a particular message (one LLM interaction) can take several seconds). [0039] This performance will of course improve as better LLM technology is developed. However, the difference to today’s traditionally constructed systems is in the order of as much as six orders of magnitude.

[0040] This can present a problem for building quick prototypes based on LLM technology, for running simulators using LLMs that understand protocols, or for generating large amounts of test data.

[0041] One approach to making a higher-performance end-result is to have the LLM generate code for behaving in a particular way (e.g., to respond as a real system (for simulators or quick prototypes) or to generate inputs needed for a test case).

[0042] However, while LLMs have been widely used in programming, they are not necessarily used in this kind of situation. For instance, most use of LLMs for programming today involves relatively small code fragments. And more importantly, there is always a human requesting a specific and detailed behaviour to be performed by the program (e.g., “open a connection to a database and search for employees matching a particular criteria”). The human may not be able to provide detailed instruction, but rather only “make it work like the examples in this large collection of protocol traces.” The human will not know what systems the program will need, or what kind of response is needed in a specific situation.

[0043] This can be analogous to asking an LLM to complete the first sentence of a book (e.g., “It was a dark and stormy night, . . .”). An LLM may be able to complete the sentence. However, it is not possible to request the LLM to write a program to complete any sentences it might be asked to complete. In a way, such a request would be a request for the LLM to produce itself so that it can be used for the sentence completion task.

[0044] Therefore, it is an outstanding question as to how to provide code generation.

[0045] There is a general approach of using a structured and step-wise process for generating more complex answers from an LLM. Such use in programming is emerging, and it is possible to start with a question to an LLM about a high-level problem (e.g., how would one go about implementing an HR people management system, and what components would such a system have?). The LLM may respond with a list of components, and it would be possible to dig deeper into each one of them, asking what is needed for each, and what tasks it would handle. And then for each task it would be possible to start to ask for specific code to perform it. However, this can be a lengthy process, can produce surprises along the way, and in any case require a lot of human supervision.

[0046] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. Various embodiments herein describe combining a formal syntax of a protocol and code generation through LLMs. In some embodiments, instead of asking a large question (e.g., “implement this protocol”), the code generation process can be guided in smaller steps. In some examples, the LLM can be instructed to check if an incoming message is of a particular type or to produce code to take whatever action is required when a given message type is received. Having a formal syntax of a protocol message can make it possible to inform the LLM about the fields of the message and how they can be accessed. This can ensure that the LLM is focused at every point on handling the specific task, and aware of the full set of fields it may need to check or set.

[0047] In some examples, combining a formal syntax of a protocol and code generation through LLMs can improve the quality of the produced code significantly, presumably due to adding more information or increasing the redundancy of the information in the training traces and in the instruction given to the LLM.

[0048] FIG. 10 illustrates an example of a packet trace of a system, recorded from a running open-source DNS resolver software. This includes training data, which can be used as input for the code generation.

[0049] FIG. 11 illustrates an example of a formal definition of a syntax of a protocol, in this case a subset of the DNS query protocol. In some examples, the formal definition defines that a DNS query protocol has Query and Answer messages, and defines their fields. In this example notation, messages consist of fields separated by a vertical bar (I) and alternatives are separated by a slash (/). Fields may have fixed values denoted by a colon (:) and some fields may be repeated when the asterisk (*) is present in front of the field. This example notation is just an example and an ASN.1 definition may work equally well.

[0050] FIG. 12 illustrates an example of a screenshot of the code generation system running. In the upper window, the code generator is running on some recorded training sample, in this case from an open-source recursive DNS resolver software. Then the system and process produce a new software module through code generation. Finally, that new module is run. In the lower window a commonly available DNS client, “host,” uses the newly generated system to retrieve some IP addresses of a domain name.

[0051] FIG. 13 illustrates an example of a generated code.

[0052] Protocol traces are available from many sources. In some examples, an existing open source or commercial product can be used under monitoring to produce traces for specific situations. A test suite or conformance test rig can be employed to go through different use cases. [0053] An ability to take protocol traces and use them to generate an implementation that correctly responds to how the examples worked can be valuable in various applications.

[0054] In some examples, the applications can include simple simulators built to behave like a real implementation, without the need to have LLMs operate the entire time that the simulator is running (and perhaps causing significant costs).

[0055] In additional or alternative examples, the applications can include test case generators built with ability to generate large number of messages without excessive cost of LLM operations for each of them.

[0056] In additional or alternative examples, the applications can include code that can be produced to react to specific situations in a timely manner, without delays incurred by asking the LLM for an action, as the actions have already been coded in the generated implementation.

[0057] In additional or alternative examples, the applications can include code produced to match a specific environment. For instance, even if a “real” implementation in C that runs on a CPU exists, it might be desired to trace that implementation, and use the traces to generate another implementation that runs in a very specific environment, such as in a network interface card using eBPF/XDP, on a DSP, etc.

[0058] In additional or alternative examples, the application can include an actual implementation being generated. However, a real implementation that handles all the necessary corner cases may be more difficult to produce. The ability to produce such an implementation depends on the size and nature of the protocol traces used as training material. It also depends on the ability the code guiding the LLM and the LLM itself to produce code.

[0059] Embodiments herein describe highly guided LLM usage, where instead of large questions such as “write a program for a DNS resolver” a large number of more detailed questions are used that are more likely going to ensure that the LLM does not forget any specific angle or protocol field, everything is checked, and new messages are constructed correctly, regardless of the data type of the fields in the messages. Some embodiments provide a very specific way of using a formal protocol syntax to guide the process.

[0060] Earlier code generation was compared to completing a sentence. In some examples, the situation is not as wide open as it is in sentence completion. With protocols, a large amount of context information can be available. For example, the protocol behavior in the training traces and/or example implementations of (same or other) protocols may be available.

[0061] Some embodiments herein assume that there is a formal protocol format definition underlying the binary protocol messages. In a practical sense, this is often true. Many protocols have formal syntaxes defined in ASN.l or AB NF, for instance. In any case, it can be a useful tool also for making the code generation work as well.

[0062] In some embodiments, a procedure can be used to generate code that works using the formal protocol syntax. An example procedure is describe below of a server-side behavior (e.g., when frying to produce code that would replicate the behavior of a server receiving messages from clients).

[0063] In this example, the protocol training traces can be provided to the LLM.

Furthermore, example implementation or implementations of other protocols can be provided to the LLM.

[0064] The formal syntax definition can be considered as a tree. For instance, if a message is the top level of the tree, then there may be several different types of messages as alternatives (request, response, etc.) and then each type of message consists of individual fields, which in turn may have some variation, etc.

[0065] The LLM can be requested to provide a template that protocol implementations require, e.g., to set up listening to the right sockets, etc. This request should accompany the definition of what kind of a protocol arrangement is in question, e.g., a client and server require different code. In the case of a server, for example, the template should also include waiting for the reception of the next input message.

[0066] The LLM can be asked for a list of all possible messages that a node in the given role (e.g., a server) can receive. Save the description of each item on the list, as given by the LLM.

[0067] For each of the message descriptions M from the LLM, the following sub-operations can be performed:

• Generate a list of alternative message type names L, using walkalt(T), where T is the entire formal syntax of the protocol. For instance, in many protocols the list has two items, request and response.

• Ask the LLM which of the alternatives does M correspond to? It corresponds to alternative A. Say, a request.

• Determine Tm by retrieving the formal syntax for the part of the protocol that corresponds to an alternative named A in T.

• Determine the list of fields in the formal syntax Tm, using walkfields(Tm). Let us call this list F. • Then ask the LLM for program function to check for appropriate values in fields F when M is received. Provide the LLM information how to access each individual field in F = {F1,F2,F3, ...) (e.g., “getField(‘Fl’)”).

• Some of the field values may be complex, e.g., a list of 0..N attributes. For each part of the message syntax tree where this is the case, ask the LLM specific question about the desired value: o Should this optional field be included in this case? o Should this sequence/list field have how many entries? o And then for each entry, what should its value be? o Along with these questions the LLM can be provided an example code how to set/unset an optional field, how to allocate space in a message for a given number of sequence entries, etc.

• Create a program code that calls the functions from Step 6.v. to check for all of them in an if statement.

• Ask the LLM if a specific message needs to be sent in response, call this message R if there is one. If there is one, perform the next sub-sub steps: o If there is a message R, ask the which of the alternative message types in L it is. Call this answer Mr. o Determine Tr by retrieving the formal syntax for the part of the protocol that corresponds to an alternative named Mr in T. o Determine the list of fields in the formal syntax Tr, using walkfields(Tr). Let us call this list Fr. o Ask the LLM how to set the fields Fr in the new message. Provide context for the LLM on how to access (a) the input message and (b) set a field in the new message.

[0068] The LLM can be further requested to provide a post-amble for the expected kind of protocol implementation (e.g., return to start to wait for more messages (server) or closing sockets after a task is performed (client), etc).

[0069] In some embodiments, the procedure can include a formal syntax tree walking operation. In some examples, the formal syntax tree walking operation lists the alternative message formats: walkalt(T) if T has alternatives, return their names if T is a named composite, individual field or other type, return the name of that

[0070] In additional or alternative examples, the formal syntax tree walking operation lists the fields. walkfields(T) if T is a type that is fully defined by the syntax

(e.g., a tag field with a specific value), return the empty list if T is an individual field, return the field’s name if T is a composite structure, return the union of walkfields(Tp) for each part P in the composite

[0071] In additional or alternative embodiments, the formal syntax tree walking operation that lists alternative message formats can be associated with how messages are represented to the LLM (binary vs. something else).

[0072] In additional or alternative embodiments, the formal syntax tree walking operations that lists the fields can be associated with what is considered a protocol message (just actual messages sent on the network, but also e.g. operating system calls).

[0073] Embodiments associated with providing protocol messages to the LLM are described below. Although it may be believed that current LLMs would have difficulty processing binary data in the different fields of messages. This assumption may be incorrect. Providing (for instance) hex values still enables the LLM to learn patterns in the communication. For instance, it still recognizes what data should be copied from a specific field in a request to another field in a response or what options need to be added where.

[0074] However, a symbolic representation is helpful for another reason: it is difficult for the LLMs to deal with protocol message aspects that involve mathematical operations, such as length or checksum fields, encryption, identifier fields that link messages together, and so on. Traditional message syntax definitions can be combined with symbolic representations and then fed to the LLM. For instance, a message format with a checksum field followed by an octet string could be represented as "Csum = CSUM(Payload) I Payload = Oxaabbccddeeff '. As long as the system supporting the LLM can parse and construct such messages, it is easy for the LLM to consume and produce such symbolic messages. With the same type and amount of training, the LLM with just binary input differed from the LLM with symbolic input. The LLM with binary input was unable to deal with the above issues, but with the symbolic format, the LLM was easily able to deal with the issues. That this happens is perhaps not a surprise, given that LLMs are generally unable to directly perform mathematical operations. Also, many advanced Al applications such as reasoning employ similar symbolic techniques, here a symbolic technique can be used to support the LLM and the code generator to operate at the right abstraction level. For instance, the code generator does not have to deal with checksums, as that is provided by the underlying message parser/constructor.

[0075] FIG. 3 illustrates an example of a system including a message parser 302 and a message constructor 304. In this example, a network 200 can communicate with the system via sockets 306. Information associated with received messages via sockets 306 can be parsed by the message parser and used to generate the program code 300. The program code 300 can generate a message constructed by the message constructor 304 to be transmitted via the sockets 306.

[0076] The program code 300 can use an underlying library to receive and send messages. This library also handles parsing and constructing binary messages (e.g., mapping from binary to parsed (received message), and from parsed to binary (sent message)). Such message parser/constructor code is typically auto-generated from ASN.1 and other formal definitions of syntax.

[0077] At the same time, this library can also optionally handle math-based fields (checksums etc.) in symbolic notation (e.g., it will represent checksums not as numbers but as a math formula that the generated code can just supply exactly the same way as it appeared in the training input traces).

[0078] Embodiments associated with recording behavior and replicating it in code beyond protocols are described below and FIG. 2. Protocols are just one aspect of complex system behavior. In many cases protocol traces are not sufficient to define behavior. However, other external interfaces (e.g., system calls etc.) can provide a full picture. A web server has a protocol interface, but also complex other functionality such as interaction with the file system for content and log files. A web server viewed only through the protocol lens would be a mythical creature, coming up with content without apparent explanation why this particular content was provided.

[0079] As a result, any observations about the behavior are at best partial, the function of the web server is not defined solely by the protocol interface. This can be rectified by observing the system across all of its external interfaces. FIG. 2, for example, illustrates a web server 202 including an application 204 and a memory 206. The behavior of the web server 202 both on a network interface 200a and file related system call interfaces can be recorded as observations 208 using tools such as the Linux system call tracing command, strace. In this example, the LLM is enabled to learn the behavior of opening files requested on GET requests and providing the content of those files in responses.

[0080] From a code generator perspective, these are just another type of a response. A protocol message comes in, it causes a “message” to be sent to the operating system to open a file. The same code generation approach as outlined earlier works for these “messages” as well, as long as the underlying support libraries understand how to “send” a request to the operating system. As a result, the code generation can produce code to not only send and receive protocol messages but interact with the operating system.

[0081] As a further interesting complication, allowing LLMs or LLM- generated code free access to operating system calls is unlikely wise. Therefore, it is essential that the libraries used to support the code generated program restrict access to resources in the operating system. For instance, the Linux “chroot” mechanism can be used to restrict a particular process to only have access to a certain directory sub-tree of the full file system.

[0082] This type of implementation of protocols based on protocol traces is not directly impacting specifications. In some cases, one might imagine that it could perhaps reduce the need for some specifications to be published at all, if behavior can be copied without a written specification. However, that seems unlikely.

[0083] However, the use of LLMs in networking systems is a highly popular topic at this time. It is likely that mechanisms for feeding protocol traces to LLMs and their use in code generation and other tasks will be published very shortly.

[0084] FIG. 18 is a block diagram illustrating a non-limiting example of a system deployment in accordance with some embodiments. As shown in this example, the system includes three nodes. A first node 1800 includes a control program 1802 and an LLM library 1804. A second node 1806 includes LLM 1808. A third node 1810 includes a code generated program 1812. The code generated program 1812 is provided from the control program of the first node 1800, which includes the program code generated by LLM 1808 and provided to the control program 1802. The third node 1810 can connect at least the program code, or a program that includes the program code, to a communication channel, such as a socket(s) that is communicatively connected to a network (NW).

[0085] Control program 1802 controls inputs to the LLM 1808. The inputs include, without limitation, packet trace files that the control program reads, converts the inputs from the trace files to a suitable form for the LLM. Control program 1802 also gives instructions to the LLM 1808 to generate the program code; and controls outputs, including the program code generated by the LLM, to third node 1810. Alternatively, the control program 1802 can output to third node 1810 a complete program that includes the program code generated by LLM 1808.

[0086] In the example in Figure 18, an LLM library 1804 in the first node 1800 is used to perform the LLM operations in an LLM 1808 in second node 1806 (e.g., a cloud computer). [0087] FIG. 19 is a block diagram illustrating another non-limiting example of a system deployment in accordance with some embodiments. As shown in this example, the system includes two nodes 1900, 1906 and the LLM 1904 is included in the first node 1900. In this example, LLM 1904, e.g., an open source LLM, is run on first node 1900 and the library calls are internal interfaces.

[0088] A first node 1900 also includes control program 1902. Second node 1906 includes a code generated program 1812. The code generated program 1812 is provided from the control program of the first node 1900, which includes the program code generated by LLM 1904 and provided to the control program 1902. The second node 1906 can connect at least the program code, or a program that includes the program code, to a communication channel, such as a socket(s) that is communicatively connected to a NW.

[0089] Control program 1902 controls inputs to the LLM 1908. The inputs include, without limitation, packet trace files that the control program reads, converts the inputs from the trace files to a suitable form for the LLM. Control program 1902 also gives instructions to the LLM 1904 to generate the program code; and controls outputs, including the program code generated by the LLM 1904, to second node 1906. Alternatively, the control program 1902 can output to second node 1906 a complete program that includes the program code generated by LLM 1904. [0090] Operations of a system for generation of program code by a LLM to implement a protocol will now be discussed with reference to the flow chart of FIG. 4 according to some embodiments of inventive concepts. The system includes at least three nodes and each of the first, second, and third nodes 500 may have modules that may be stored in memory 510 of Figure 5, and these modules may provide instructions so that when the instructions of a module are executed by respective node processing circuitry 502, node 500 performs respective operations of the flow chart.

[0091] At block 400, processing circuitry 502 of a first node including a control program and an LLM library provides, to a second node comprising the LLM, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication.

[0092] At block 402, processing circuitry 502 requests, based on a hierarchical use of a syntax of the protocol from the at least one trace, that the second node generates program code to check whether a machine in the machine-to-machine communication received at least a first message from the plurality of messages in the at least one trace. The syntax includes respective message types in a plurality of message types.

[0093] At block 404, processing circuitry 502 in the second node generates the program code in the LLM of the second node to implement a third node with a behavior seen in the at least one trace provided to the LLM.

[0094] At block 406, processing circuitry 406 provides the program code to the third node to execute the program code.

[0095] Various operations from the flow chart of FIG. 4 may be optional with respect to some embodiments of nodes and related methods.

[0096] Operations of the first node 500 (implemented using the structure of Figure 5) for requesting generation of program code to implement a protocol will now be discussed with reference to the flow chart of FIG. 14 according to some embodiments of inventive concepts. For example, modules may be stored in memory 510 of a first node 500 of Figure 5, and these modules may provide instructions so that when the instructions of a module are executed by respective first node processing circuitry 502, the first node performs respective operations of the flow chart.

[0097] The program code can include an organization of the program code based on information from a template. At block 1400, the processing circuitry 502 accesses the template for the organization of the program code for a node.

[0098] At block 1402, processing circuitry 502 provides the template to the second node for the LLM.

[0099] At block 1404, processing circuitry 502 provides, to a second node including the LLM at least one trace of a plurality of messages from a protocol in a machine-to-machine communication.

[0100] At block 1406, processing circuitry 502 requests, based on a hierarchical use of a syntax of the protocol from the at least one trace in a form that can be processed by the LLM, that the second node generate program code to check whether a machine in the machine-to- machine communication received at least a first message in the at least one trace of the plurality of messages from the protocol. The hierarchical use of the syntax can include to determine from the syntax, a syntax of at least one of respective fields in at least the first message, respective fields in at least an alternative message type to at least the first message, respective fields in a response message to at least the first message, and respective fields in an alternative message type to the response message. [0101] In some embodiments, the hierarchical use of the syntax includes receiving from the second node based on information from the syntax of the protocol in the form that the LLM can process, an identity of a name of any alternative message type for a respective message type from the plurality of message types and an identity of respective names of respective fields of the alternative message type, and an identity of the respective fields of the alternative message type-

[0102] A respective message in the plurality of messages can include a description of an event in the at least one trace.

[0103] In some embodiments, the syntax of the protocol includes a plurality of message types, a respective message type in the plurality of message types includes a plurality of fields, and a respective field in the plurality of fields includes a plurality of values.

[0104] In some embodiments, the method of any one of Claims 2 to 5, the request, based on the hierarchical use of the syntax of the protocol, includes reading the syntax and converting the syntax into the form that can be processed by the LLM.

[0105] At block 1408, processing circuitry 502 requests that the LLM generate the program code to check whether an action is taken in response to receipt of at least the first message.

[0106] At block 1410, when an action is taken in response to receipt of at least the first message, processing circuity 502 requests that the LLM generate the program code to instruct that a response message be sent in response to receipt of at least the first message.

[0107] A message type can include a plurality of fields, and a respective field in the plurality of fields can include a plurality of values. The syntax of the protocol can include further information about respective values in the respective field.

[0108] At block 1412, processing circuitry receives the program code from the second node.

[0109] At block 1414, processing circuitry 502 appends the program code to a program to check whether a message has been received from the at least one trace.

[0110] In additional or alternative embodiments, at block 1416, processing circuitry 502 appends the program code to a program where a check for a received message has succeeded.

[0111] At block 1418, processing circuitry 502 outputs at least the program code program code to a third node to execute at least the program code.

[0112] Various operations from the flow chart of FIG. 14 may be optional with respect to some embodiments of first nodes and related methods.

[0113] Operations of the second node 500 (implemented using the structure of Figure 5) will now be discussed with reference to the flow chart of FIG. 15 according to some embodiments of inventive concepts. For example, modules may be stored in memory 510 of a second node 500 of Figure 5, and these modules may provide instructions so that when the instructions of a module are executed by respective second node processing circuitry 502, the second node performs respective operations of the flow chart.

[0114] At block 1500, processing circuitry 502 receives, a template from a first node. Program code can include an organization based on information from the template.

[0115] At block 1502, processing circuitry 502 from a first node based on a syntax of a protocol from at least one trace that is in a form that the LLM can process, a request to generate a program code to check whether a machine in a machine-to-machine communication received at least a first message in at least one trace of a plurality of messages from the protocol. In additional or alternative embodiments, receiving the request includes a request at the LLM to identify a plurality of messages that the third node can receive according to the at least one trace; and/or receiving the request further includes a request to generate the program code to send a first message based on the information from the at least one trace.

[0116] In yet additional or alternative embodiments, receiving the request includes a request at the LLM to identify a response message to the received message from the plurality of messages to be sent according to the at least one trace, and a request at the LLM to identify a name of the response message. In such embodiments, receiving the request can further include receiving at the LLM information about a type of the response message, which fields are included in the type of response message, a type of the respective fields, and how the respective fields can be accessed, and receiving at the LLM a request to generate program code to send the response message based on the information.

[0117] At block 1504, processing circuitry 502 generates the program code in the LLM to implement a third node with a behavior seen in the at least one trace based. The program code includes at least one of a check for at least one received message and an instruction to send at least one new message based on the received message. In additional or alternative embodiments, generating the program code further includes employing the information from the template to organize the program code. In additional or alternative embodiments, the program code is generated to cause a response message to be sent in response to a received message from the plurality of messages.

[0118] In yet additional or alternative embodiments, the behavior seen in the at least one trace includes an observation, the observation includes at least one event, and the event includes at least one protocol message that sends or receives the at least one event and a system call. The at least one event can include at least one of (i) the system call including a call to an operating system of at least one machine and the behavior of the at least one machine in response to the call to the operating system, and (ii) a call to a library and the response to the call to the library. [0119] In some embodiments, the at least one trace of the plurality of messages from the protocol includes at least one packet.

[0120] In further additional or alternative embodiments, the hierarchical use of the syntax includes (i) from the syntax of the protocol, to identify a name of any alternative message type for a respective message type from the plurality of message types and identity respective names of respective fields of the alternative message type, and (ii) to identify the respective fields of the alternative message type.

[0121] In yet additional or alternative embodiments, the hierarchical use of the syntax includes, for the respective messages in the plurality of messages, to perform at least one of the following operations (i) identify respective alternative message types for respective messages in the plurality of messages that the third node can receive, and (iii) for each alternative message type, the LLM has information from the at least one trace about a response message type, which fields are included in the response message type and respective types of the fields, and how the fields can be accessed.

[0122] In further additional or alternative embodiments, the hierarchical use of the syntax includes to perform identify an alternative message type the name of the response message corresponds to.

[0123] At block 1506, processing circuitry 502 provides at least the program code to the first node. In additional or alternative embodiments, the implementation of the protocol includes at least one of generating data, running a simulator using the LLM that understands the protocol, performing tasks, implementing a node that supports the protocol, optimizing a task, and an actual implementation using the LLM that understands the protocol. Generating the data can include generating data for a test case.

[0124] In some embodiments, at least one respective message in a plurality of messages in the protocol includes a symbolic representation of at least one field or at least one value in a field of the at least one respective message type.

[0125] In other embodiments, the symbolic representation of at least one field or at least one value in a field of the at least of the respective message type includes a symbolic form of a length field, and the at least one trace provided to the LLM and events processed by a program resulting from the program code generation carry a symbol representing a length field calculation, without providing a value for the length and referring to another field in a same message type whose length is included in the message when actually sent.

[0126] Various operations from the flow chart of FIG. 15 may be optional with respect to some embodiments of second nodes and related methods.

[0127] Operations of the third node 500 (implemented using the structure of Figure 5) for implementation of a protocol based on program code generated by the LLM will now be discussed with reference to the flow chart of FIG. 16 according to some embodiments of inventive concepts. For example, modules may be stored in memory 510 of a third node 500 of Figure 5, and these modules may provide instructions so that when the instructions of a module are executed by respective third node processing circuitry 502, the third node performs respective operations of the flow chart.

[0128] At block 1600, processing circuitry 502 receives a program code from a first node to implement a system with a behavior seen in at least one trace of a plurality of messages from a protocol in a machine-to-machine communication. In additional or alternative embodiments, the behavior seen in the at least one trace includes an observation, the observation includes at least one event, and the event includes at least one of protocol message that sends or receives the at least one event and a system call.

[0129] In some embodiments, the at least one event includes at least one of (i) the system call including a call to an operating system of at least one machine and the behavior of the at least one machine in response to the call to the operating system, and (ii) a call to a library and the response to the call to the library. In additional or alternative embodiments, at least one underlying library provides the at least one trace to the LLM.

[0130] In additional or alternative embodiments, the at least one trace of the plurality of messages from the protocol comprises at least one packet.

[0131] At block 1602, processing circuitry 502 connects at least the program code to a communication channel.

[0132] At block 1604, processing circuitry 502 executes at least the program code. In additional or alternative embodiments, executing the program code includes processing with at least the program code the at least one event based on a received check length field values and computing the check length field values upon sending a message.

[0133] In further additional or alternative embodiments, the program code includes a symbolic representation of at least one field or at least one value in a field of at least one respective message type. The symbolic representation includes a symbolic form of at least one of a length field, checksum field, an encryption field, and a cryptographic field. [0134] In yet further or alternative embodiments, executing the program code includes processing events in the at least one trace with at least the program code that includes a symbol representing at least one length field calculation, a checksum calculation, an encryption calculation, and a cryptographic field calculation, without providing a value for the calculation and that refers to other fields or other known values in a same message type acting as input for a calculation that is included in a message when the third node sends the message. At least one underlying library that provided the at least one trace to the LLM is used by a program including the program code to check for the at least one checksum, encryption, and cryptographic calculation upon reception and perform the calculation to include when the thirds node sends the message.

[0135] In some embodiments, the third node is at least one of a cloud-based node, a user equipment (UE), and a network node.

[0136] Various operations from the flow chart of FIG. 16 may be optional with respect to some embodiments of second nodes and related methods.

[0137] Operations of a system for generation of program code by a LLM to implement a protocol will now be discussed with reference to the flow chart of FIG. 17 according to some embodiments of inventive concepts. The system includes at least two nodes and each of the first and second nodes 500 may have modules that may be stored in memory 510 of Figure 5 and these modules may provide instructions so that when the instructions of a module are executed by respective node processing circuitry 502, node 500 performs respective operations of the flow chart.

[0138] At block 1700, processing circuitry 502 accesses, by a control program, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication.

[0139] At block 1702, processing circuitry 502 accesses, by the control program, a syntax of the protocol.

[0140] At block 1704, processing circuitry 502 accesses, by the control program, a template for another protocol implementation as an example for a structure of the program code.

[0141] At block 1706, processing circuitry 502 provides, by the control program, the at least one trace to the LLM as an example of a behavior of at least one node.

[0142] At block 1708, processing circuitry 502 provides, by the control program, the LLM the template.

[0143] At block 1710, processing circuitry 502 requests, based on a hierarchical use of a syntax of the protocol from the at least one trace, that the LLM generate program code to check whether a machine in the machine-to-machine communication received at least a first message from the plurality of messages in the at least one trace. The syntax includes respective message types in a plurality of message types. In additional or alternative embodiments, the request that the LLM generate the program code includes requesting that the LLM generate the program code to implement the protocol based on information provided to the LLM by the control program about at least one received message and at least one sent message, wherein the information is from a syntax of the protocol and is in a form that can be processed by the LLM. [0144] At block 1712, processing circuitry 502 generates the program code in the LLM to implement a second node with a behavior seen in the at least one trace provided to the LLM. [0145] At block 1714, processing circuitry 502 composes, by the control program, a program from the template and the program code generated by the LLM.

[0146] At block 1716, processing circuitry 502 provides, by the control program, at least the program code to a second node to execute at least the program code.

[0147] The machine-to-machine communication can include machine-to-machine communication in at least one of a telecommunications network, a communications network, and an Internet network. In some embodiments, the machine-to-machine communication is an on-premise network such as a factory.

[0148] FIG. 6 shows an example of a communication system 600 in accordance with some embodiments.

[0149] In the example, the communication system 600 includes a telecommunication network 602 that includes an access network 604, such as a radio access network (RAN), and a core network 606, which includes one or more core network nodes 608. The access network 604 includes one or more access network nodes, such as network nodes 610a and 610b (one or more of which may be generally referred to as network nodes 610), or any other similar 3^rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 602 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 602 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 602, including one or more network nodes 610 and/or core network nodes 608. [0150] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the 0-RAN Alliance or comparable technologies. The network nodes 610 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 612a, 612b, 612c, and 612d (one or more of which may be generally referred to as UEs 612) to the core network 606 over one or more wireless connections.

[0151] Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 600 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 600 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

[0152] The UEs 612 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 610 and other communication devices. Similarly, the network nodes 610 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 612 and/or with other network nodes or equipment in the telecommunication network 602 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 602. [0153] In the depicted example, the core network 606 connects the network nodes 610 to one or more host computing systems, such as host 616. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 606 includes one more core network nodes (e.g., core network node 608) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 608. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

[0154] The host 616 may be under the ownership or control of a service provider other than an operator or provider of the access network 604 and/or the telecommunication network 602. The host 616 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0155] As a whole, the communication system 600 of FIG. 6 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. [0156] In some examples, the telecommunication network 602 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 602 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 602. For example, the telecommunications network 602 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive loT services to yet further UEs. [0157] In some examples, the UEs 612 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 604 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 604. Additionally, a UE may be configured for operating in single- or multi-RAT or multi- standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved- UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0158] In the example, the hub 614 communicates with the access network 604 to facilitate indirect communication between one or more UEs (e.g., UE 612c and/or 612d) and network nodes (e.g., network node 610b). In some examples, the hub 614 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 614 may be a broadband router enabling access to the core network 606 for the UEs. As another example, the hub 614 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 610, or by executable code, script, process, or other instructions in the hub 614. As another example, the hub 614 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 614 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub 614 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 614 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 614 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0159] The hub 614 may have a constant/persistent or intermittent connection to the network node 610b. The hub 614 may also allow for a different communication scheme and/or schedule between the hub 614 and UEs (e.g., UE 612c and/or 612d), and between the hub 614 and the core network 606. In other examples, the hub 614 is connected to the core network 606 and/or one or more UEs via a wired connection. Moreover, the hub 614 may be configured to connect to an M2M service provider over the access network 604 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 610 while still connected via the hub 614 via a wired or wireless connection. In some embodiments, the hub 614 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 610b. In other embodiments, the hub 614 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 610b, but which is additionally capable of operating as a communication start and/or end point for certain data channels. [0160] FIG. 7 shows a UE 700 in accordance with some embodiments. The UE 700 presents additional details of some embodiments of the UE 612 of FIG. 6. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage/playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

[0161] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and/or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). [0162] The UE 700 includes processing circuitry 702 that is operatively coupled via a bus 704 to an input/output interface 706, a power source 708, a memory 710, a communication interface 712, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIG. 7. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0163] The processing circuitry 702 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 710. The processing circuitry 702 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 702 may include multiple central processing units (CPUs).

[0164] In the example, the input/output interface 706 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 700. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0165] In some embodiments, the power source 708 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 708 may further include power circuitry for delivering power from the power source 708 itself, and/or an external power source, to the various parts of the UE 700 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 708. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 708 to make the power suitable for the respective components of the UE 700 to which power is supplied.

[0166] The memory 710 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable readonly memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 710 includes one or more application programs 714, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 716. The memory 710 may store, for use by the UE 700, any of a variety of various operating systems or combinations of operating systems.

[0167] The memory 710 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and/or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 710 may allow the UE 700 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 710, which may be or comprise a device -readable storage medium.

[0168] The processing circuitry 702 may be configured to communicate with an access network or other network using the communication interface 712. The communication interface 712 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 722. The communication interface 712 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 718 and/or a receiver 720 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 718 and receiver 720 may be coupled to one or more antennas (e.g., antenna 722) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0169] In the illustrated embodiment, communication functions of the communication interface 712 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short- range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol/internet protocol (TCP/IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth. [0170] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 712, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0171] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0172] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and/or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 700 shown in FIG. 7.

[0173] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another UE and/or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

[0174] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0175] FIG. 8 shows a network node 800 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0176] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0177] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs).

[0178] The network node 800 includes a processing circuitry 802, a memory 804, a communication interface 806, and a power source 808. The network node 800 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 800 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 800 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 804 for different RATs) and some components may be reused (e.g., a same antenna 810 may be shared by different RATs). The network node 800 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 800, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 800.

[0179] The processing circuitry 802 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 800 components, such as the memory 804, to provide network node 800 functionality.

[0180] In some embodiments, the processing circuitry 802 includes a system on a chip (SOC). In some embodiments, the processing circuitry 802 includes one or more of radio frequency (RF) transceiver circuitry 812 and baseband processing circuitry 814. In some embodiments, the radio frequency (RF) transceiver circuitry 812 and the baseband processing circuitry 814 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 812 and baseband processing circuitry 814 may be on the same chip or set of chips, boards, or units. [0181] The memory 804 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 802. The memory 804 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 802 and utilized by the network node 800. The memory 804 may be used to store any calculations made by the processing circuitry 802 and/or any data received via the communication interface 806. In some embodiments, the processing circuitry 802 and memory 804 is integrated.

[0182] The communication interface 806 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface 806 comprises port(s)/terminal(s) 816 to send and receive data, for example to and from a network over a wired connection. The communication interface 806 also includes radio front-end circuitry 818 that may be coupled to, or in certain embodiments a part of, the antenna 810. Radio front-end circuitry 818 comprises filters 820 and amplifiers 822. The radio front-end circuitry 818 may be connected to an antenna 810 and processing circuitry 802. The radio front-end circuitry may be configured to condition signals communicated between antenna 810 and processing circuitry 802. The radio front-end circuitry 818 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 818 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 820 and/or amplifiers 822. The radio signal may then be transmitted via the antenna 810. Similarly, when receiving data, the antenna 810 may collect radio signals which are then converted into digital data by the radio front-end circuitry 818. The digital data may be passed to the processing circuitry 802. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

[0183] In certain alternative embodiments, the network node 800 does not include separate radio front-end circuitry 818, instead, the processing circuitry 802 includes radio front-end circuitry and is connected to the antenna 810. Similarly, in some embodiments, all or some of the RF transceiver circuitry 812 is part of the communication interface 806. In still other embodiments, the communication interface 806 includes one or more ports or terminals 816, the radio front-end circuitry 818, and the RF transceiver circuitry 812, as part of a radio unit (not shown), and the communication interface 806 communicates with the baseband processing circuitry 814, which is part of a digital unit (not shown).

[0184] The antenna 810 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 810 may be coupled to the radio front-end circuitry 818 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 810 is separate from the network node 800 and connectable to the network node 800 through an interface or port.

[0185] The antenna 810, communication interface 806, and/or the processing circuitry 802 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, the antenna 810, the communication interface 806, and/or the processing circuitry 802 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment.

[0186] The power source 808 provides power to the various components of network node

800 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 808 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 800 with power for performing the functionality described herein. For example, the network node 800 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 808. As a further example, the power source 808 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0187] Embodiments of the network node 800 may include additional components beyond those shown in FIG. 8 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node 800 may include user interface equipment to allow input of information into the network node 800 and to allow output of information from the network node 800. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 800. In some embodiments providing a core network node, such as core network node 108 of FIG. 6, some components, such as the radio front-end circuitry 818 and the RF transceiver circuitry 812 may be omitted.

[0188] FIG. 9 is a block diagram illustrating a virtualization environment 900 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 900 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 900 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

[0189] Applications 902 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

[0190] Hardware 904 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 908a and 908b (one or more of which may be generally referred to as VMs 908), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 906 may present a virtual operating platform that appears like networking hardware to the VMs 908.

[0191] The VMs 908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 906. Different embodiments of the instance of a virtual appliance 902 may be implemented on one or more of VMs 908, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0192] In the context of NFV, a VM 908 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non- virtualized machine. Each of the VMs 908, and that part of hardware 904 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 908 on top of the hardware 904 and corresponds to the application 902.

[0193] Hardware 904 may be implemented in a standalone network node with generic or specific components. Hardware 904 may implement some functions via virtualization. Alternatively, hardware 904 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 910, which, among others, oversees lifecycle management of applications 902. In some embodiments, hardware 904 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 912 which may alternatively be used for communication between hardware nodes and radio units.

[0194] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0195] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

Claims

CLAIMS What is Claimed is:

1. A computer-implemented method performed by a system for generation of program code by a large language model, LLM, to implement a protocol, the method comprising: providing (400), by a first node comprising a control program and an LLM library to a second node comprising the LLM, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; requesting (402), based on a hierarchical use of a syntax of the protocol from the at least one trace, that the second node generate program code to check whether a machine in the machine-to-machine communication received at least a first message from the plurality of messages in the at least one trace, the syntax comprising respective message types in a plurality of message types; generating (404) the program code in the LLM of the second node to implement a third node with a behavior seen in the at least one trace provided to the LLM; and providing (406) at least the program code to the third node to execute the program code.

2. A computer-implemented method performed by a first node comprising a control program and a large language model (LLM) library for generation of program code, the method comprising: providing (140), to a second node comprising a large language model, LLM, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; requesting (1406), based on a hierarchical use of a syntax of the protocol from the at least one trace in a form that can be processed by the LLM, that the second node generate program code to check whether a machine in the machine-to-machine communication received at least a first message in the at least one trace of the plurality of messages from the protocol.

3. The method of Claim 2, wherein a respective message in the plurality of messages comprises a description of an event in the at least one trace.

4. The method of any one of Claims 2 to 3, wherein the program code comprises an organization of the program code based on information from a template, the method further comprising: accessing (1400) the template for the organization of the program code for a node; and providing (1402) the template to the second node for the LLM.

5. The method of any one of Claims 2 to 4, wherein the syntax of the protocol comprises a plurality of message types, a respective message type in the plurality of message types comprises a plurality of fields, and a respective field in the plurality of fields comprises a plurality of values.

6. The method of any one of Claims 2 to 5, wherein the requesting (1406), based on the hierarchical use of the syntax of the protocol, comprises reading the syntax and converting the syntax into the form that can be processed by the LLM.

7. The method of any one of Claims 2 to 6, further comprising: requesting (1408) that the LLM generate the program code to check whether an action is taken in response to receipt of at least the first message, and when an action is taken in response to receipt of at least the first message, requesting (1410) that the LLM generate the program code to instruct that a response message be sent in response to receipt of at least the first message.

8. The method of any one of Claims 5 to 7, wherein a message type comprises a plurality of fields, and a respective field in the plurality of fields comprises a plurality of values.

9. The method of any one of Claims 2 to 8, wherein the syntax of the protocol comprises further information about respective values in the respective field.

10. The method of any one of Claims 2 to 9, wherein based on a hierarchical use of a syntax further comprises to determine from the syntax, a syntax of at least one of respective fields in at least the first message, respective fields in at least an alternative message type to at least the first message, respective fields in a response message to at least the first message, and respective fields in an alternative message type to the response message.

11. The method of any one of Claims 2 to 10, wherein the hierarchical use of the syntax comprises receiving from the second node based on information from the syntax of the protocol in the form that the LLM can process, an identity of a name of any alternative message type for a respective message type from the plurality of message types and an identity of respective names of respective fields of the alternative message type, and an identity of the respective fields of the alternative message type.

12. The method of any one of Claims 2 to 11, further comprising: appending (1414) the program code to check whether a message has been received from the at least one trace.

13. The method of any one of Claims 2 to 12, further comprising: appending (1416) the program code to a program where a check for a received message has succeeded.

14. The method of any one of Claims 2 to 13, the method further comprising: receiving (1412) the program code from the second node; and outputting (1418) at least the program code program code to a third node to execute at least the program code.

15. A computer-implemented method performed by a second node comprising a large language model, LLM, for generation of program code by the LLM to implement a protocol, the method comprising: receiving (1502), from a first node based on a syntax of the protocol from the at least one trace that is in a form that the LLM can process, a request to generate a program code to check whether a machine in a machine-to-machine communication received at least a first message in at least one trace of a plurality of messages from the protocol; generating (1504) the program code in the LLM to implement a third node with a behavior seen in the at least one trace, the program code comprising at least one of a check for at least one received message and an instruction to send at least one new message based on the received message; and providing (1506) at least the program code to the first node.

16. The method of Claim 15, wherein the program code comprises an organization of the program code based on information from a template, the method further comprising: receiving (1500) the template from the first node, and wherein the generating (1504) further comprises employing the information from the template to generate the program code.

17. The method of any one of Claims 15 to 16, wherein the receiving (1502) the request comprises a request at the LLM to identify a plurality of messages that the third node can receive according to the at least one trace, wherein the hierarchical use of the syntax comprises, for the respective messages in the plurality of messages, perform at least one of the following operations (i) identify respective alternative message types for respective messages in the plurality of messages that the third node can receive, and (ii) for each alternative message type, the LLM has information from the at least one trace about a response message type, which fields are included in the response message type and respective types of the fields, and how the fields can be accessed.

18. The method of Claim 17, wherein the program code is generated to cause a response message to be sent in response to a received message from the plurality of messages, wherein the receiving (1502) the request comprises a request at the LLM to identify a response message to the received message from the plurality of messages to be sent according to the at least one trace, and a request at the LLM to identify a name of the response message, and wherein the hierarchical use of the syntax comprises to perform the following operations identify an alternative message type the name of the response message corresponds to, and wherein the receiving (1502) the request further comprises receive at the LLM information about a type of the response message, which fields are included in the type of response message, a type of the respective fields, and how the respective fields can be accessed, and receive at the LLM a request to generate program code to send the response message based on the information.

19. The method of any one of Claims 15 to 18, wherein at least one respective message in a plurality of messages in the protocol comprises a symbolic representation of at least one field or at least one value in a field of the at least one respective message type.

20. The method of Claim 19, where the symbolic representation of at least one field or at least one value in a field of the at least of the respective message type comprises a symbolic form of at least one of a length field, a checksum field, an encryption field, and a cryptographic field, and wherein the at least one trace provided to the LLM and events processed by a program resulting from the program code generation carry a symbol representing at least one of a length field calculation, a checksum field calculation, an encryption field calculation, and a cryptographic field calculation without providing a value for the length and referring to other fields or other known values in a same message type whose length is included in the message when actually sent.

21. The method of any one of Claims 15 to 20, wherein the behavior seen in the at least one trace comprises an observation, the observation comprises at least one event, and the event comprises at least one protocol message that sends or receives the at least one event and a system call.

22. The method of Claim 21, wherein the at least one event comprises at least one of (i) the system call comprising a call to an operating system of at least one machine and the behavior of the at least one machine in response to the call to the operating system, and (ii) a call to a library and the response to the call to the library.

23. The method of any one of Claims 15 to 22, wherein the at least one trace of the plurality of messages from the protocol comprises at least one packet.

24. The method of any one of Claims 15 to 23, wherein the implementation of the protocol comprises at least one of generating data, running a simulator using the LLM that understands the protocol, performing tasks, implementing a node that supports the protocol, optimizing a task, and an actual implementation using the LLM that understands the protocol.

25. The method of Claim 24, wherein generating data comprises generating data for a test case.

26. The method of any one of Claims 15 to 25, wherein the machine-to-machine communication comprises machine-to-machine communication in at least one of a telecommunications network, a communications network, and an Internet network.

27. A computer-implemented method performed by a third node for implementation of a protocol based on a program code generated by a large language model, LLM, the method comprising: receiving (1600) a program code from a first node to implement a system with a behavior seen in at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; and executing (1604) at least the program code.

28. The method of Claim 27, wherein the behavior seen in the at least one trace comprises an observation, the observation comprises at least one event, and the event comprises at least one of protocol message that sends or receives the at least one event and a system call.

29. The method of Claim 28, wherein the at least one event comprises at least one of (i) the system call comprising a call to an operating system of at least one machine and the behavior of the at least one machine in response to the call to the operating system, and (ii) a call to a library and the response to the call to the library.

30. The method of any one of Claims 27 to 29, wherein the at least one trace of the plurality of messages from the protocol comprises at least one packet.

31. The method of any one of Claims 15 to 30, further comprising: connecting (1602) at least the program code to a communication channel.

32. The method of any one of Claims 29 to 31, wherein at least one underlying library provided the at least one trace to the LLM, and wherein executing (1604) the program code comprises processing with at least the program code the at least one event based on a received check length field values and computing the check length field values upon sending a message.

33. The method of Claim 32, wherein the program code comprises a symbolic representation of at least one field or at least one value in a field of at least one respective message type, the symbolic representation comprising a symbolic form of at least one of a length field, a checksum field, an encryption field, and a cryptographic field, wherein executing (1604) the program code comprises processing events in the at least one trace with a at least the program code that includes a symbol representing at least one of a length field calculation, a checksum calculation, an encryption calculation, and a cryptographic field calculation, without providing a value for the calculation and that refers to other fields or other known values in a same message type acting as input for a calculation that is included in a message when the third node sends the message, and wherein the at least one underlying library that provided the at least one trace to the LLM is used by a program comprising the program code to check for the at least one checksum, encryption, and cryptographic calculation upon reception and perform the calculation to include when the thirds node sends the message.

34. The method of any one of Claims 27 to 33, wherein the third node is at least one of a cloud-based node, a user equipment (UE), and a network node.

35. A computer-implemented method performed by a system for generation of program code by a large language model, LLM, to implement a protocol, the method comprising: accessing (1700), by a control program, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; requesting (1710), based on a hierarchical use of a syntax of the protocol from the at least one trace, that the LLM generate program code to check whether a machine in the machine-to- machine communication received at least a first message from the plurality of messages in the at least one trace, the syntax including respective message types in a plurality of message types; generating (1712) the program code in the LLM to implement a second node with a behavior seen in the at least one trace provided to the LLM; and providing (1716), by the control program, at least the program code to the second node to execute at least the program code.

36. The method of Claim 35, the method further comprising: accessing (1702), by the control program, a syntax of the protocol; accessing (1704), by the control program, a template for another protocol implementation as an example for a structure of the program code; providing (1706), by the control program, the at least one trace to the LLM as an example of a behavior of at least one node; and providing (1708), by the control program, to the LLM the template.

37. The method of any one of Claims 35 to 36, wherein the requesting (1710) that the LLM generate the program code comprises requesting that the LLM generate the program code to implement the protocol based on information provided to the LLM by the control program about at least one received message and at least one sent message, wherein the information is from a syntax of the protocol and is in a form that can be processed by the LLM.

38. The method of any one of Claims 35 to 37, further comprising: composing (1714), by the control program, a program from the template and the program code generated by the LLM.

39. A first node (1800, 100, 500, 608, 610, 612, 700, 800) configured to request generation of program code to implement a protocol, the method comprising: processing circuitry (502, 702, 802); memory (1802, 1804,510, 514, 710, 714, 804) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the first node to perform operations comprising: provide, to a second node comprising a large language model, LLM, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; and request, based on a hierarchical use of a syntax of the protocol from the at least one trace in a form that can be processed by the LLM, that the second node generate program code to check whether a machine in the machine-to-machine communication received at least a first message in the at least one trace from the protocol.

40. The first node of Claim 39, wherein the operation further comprise any of the operations of Claims 3 to 14.

41. A non-transitory computer readable medium (1802, 1804, 510, 514, 710, 714, 804) including program code to be executed by processing circuitry (502, 702, 802) of a first node 1800, (100, 500, 608, 610, 612, 700, 800) to perform operations to request generation of program code, the operations comprising: provide, to a second node comprising a large language model, LLM, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; and request, based on a hierarchical use of a syntax of the protocol from the at least one trace in a form that can be processed by the LLM, that the second node generate program code to check whether a machine in the machine-to-machine communication received at least a first message in the at least one trace from the protocol.

42. The non-transitory computer readable medium (1802, 1804, 510, 514, 710, 714, 804) of Claim 43, the operations further comprising any of the operations of Claims 3 to 14.

43. A second node (1806, 102, 500, 608, 610, 612, 700, 800) configured to generate program code by a large language model, LLM, to implement a protocol, the second node comprising: processing circuitry (502, 702, 802); memory (1808, 510, 514, 710, 714, 804) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the second node to perform operations comprising: receive, from a first node, a request to generate a program code to check whether a machine in a machine-to-machine communication received at least a first message in at least one trace of a plurality of messages from a protocol; generate the program code in the LLM to implement a third node with a behavior seen in the at least one trace based on the at least one trace, the program code comprising at least one of a check for at least one received message and an instruction to send at least one new message based on the received message; and provide the program code to the first.

44. The second node of Claim 45, wherein the operations further comprise any of the operations of Claims 16 to 26.

45. A non-transitory computer readable medium (1808, 510, 514, 710, 714, 804) including a large language model, LLM, to be executed by processing circuitry (502, 702, 802) of a second node (1806, 102, 500, 608, 610, 612, 700, 800) to generate program code to implement a protocol, whereby execution of the LLM causes the LLM to perform operations comprising: receive, from a first node, a request to generate a program code to check whether a machine in a machine-to-machine communication received at least a first message in at least one trace of a plurality of messages from a protocol; generate the program code in the LLM to implement a third node with a behavior seen in the at least one trace based on the at least one trace, the program code comprising at least one of a check for at least one received message and an instruction to send at least one new message based on the received message; and provide the program code to the first node.

46. The non-transitory computer readable medium (1808, 510, 514, 710, 714, 804) of Claim 47, the operations further comprising any of the operations of Claims 16 to 26.

47. A third node (1810, 500, 608, 610, 612, 618, 700, 800) configured to implement a protocol based on a program code generated by a large language model, LLM, the third node comprising: processing circuitry (502, 702, 802); memory (51812, 10, 514, 710, 714, 804) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the third node to perform operations comprising: receive a program code from a first node to implement a system with a behavior seen in at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; and execute at least the program code.

48. The third node of Claim 49, wherein the operations further comprise any of the operations of Claims 28 to 34.

49. A non-transitory computer readable medium (1812, 510, 514, 710, 714, 804) including program code to be executed by processing circuitry (502, 702, 802) of a third node (1810, 500, 608, 610, 612, 618, 700, 800) to implement a protocol based on a program code generated by a large language model, LLM, whereby execution of the program code causes the program code to perform operations comprising: receive a program code from a first node to implement a system with a behavior seen in at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; and execute at least the program code.

50. The non-transitory computer readable medium (1812, 510, 514, 710, 714, 804) of Claim 41, the operations further comprising any of the operations of Claims 28 to 34.

51. A system (1900, 1906, 500, 608, 610, 612, 618, 700, 800) configured to generate program code by a large language model, LLM (1904,510, 514, 710, 714, 804), to implement a protocol, the first node comprising: processing circuitry (502, 702, 802); memory (510, 514, 710, 714, 804) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the third node to perform operations comprising: access, by a control program (1902, 510, 514, 710, 714, 804), at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; request, based on a hierarchical use of a syntax of the protocol from the at least one trace, that the LLM generate program code to check whether a machine in the machine-to-machine communication received at least a first message from the plurality of messages in the at least one trace, the syntax comprising respective message types in a plurality of message types; generate the program code in the LLM to implement a second node with a behavior seen in the at least one trace provided to the LLM; and provide at least the program code to the second node to execute at least the program code.

52. The first node of Claim 51, the operations further comprising any of the operations of Claims 36 to 38.

53. A non-transitory computer readable medium (1902, 1904, 1812, 510, 514, 710, 714, 804) including program code to be executed by processing circuitry (502, 702, 802) of a system (1900, 1906, 500, 608, 610, 612, 618, 700, 800) to implement a protocol based on a program code generated by a large language model, LLM, whereby execution of the program code causes the program code to perform operations comprising: access, by a control program, at least one trace of a plurality of messages from a protocol in a machine-to-machine communication; request, based on a hierarchical use of a syntax of the protocol from the at least one trace, that the LLM generate program code to check whether a machine in the machine-to-machine communication received at least a first message from the plurality of messages in the at least one trace, the syntax comprising respective message types in a plurality of message types; generate the program code in the LLM to implement a second node with a behavior seen in the at least one trace provided to the LLM; and provide at least the program code to a second node to execute at least the program code.

54. The non-transitory computer readable medium (1902, 1904, 1812, 510, 514, 710, 714, 804) of Claim 53, the operations further comprising any of the operations of Claims 36 to 38.