ISO/IEC 21559-2:2023

INTERNATIONAL ISO/IEC
STANDARD 21559-2
First edition
2023-01
Telecommunications and information
exchange between systems — Future
network protocols and mechanisms —
Part 2:
Proxy model-based quality of service
Télécommunications et échange d'informations entre systèmes —
Futurs protocoles et mécanismes de réseau —
Partie 2: Qualité de service basée sur un modèle de proxy
Reference number
© ISO/IEC 2023
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Protocol mechanisms in BFS . 3
4.1 Description of BFS . 3
4.2 General interactive nature for FHR . 4
4.2.1 FNProxy pairing situations . 4
4.2.2 Active and passive functions of FNProxy . 4
4.2.3 Interaction model of BFS with engines. 4
4.2.4 FPDU definition of BFS . 6
4.2.5 Strategy processing scheme in FNProxy . 8
4.2.6 Concept of the procedures in BFS . . 9
4.2.7 Function invoke descriptions to domains of FNQoS system .12
5 Protocol mechanisms in SFS .12
5.1 Description of SFS . 12
5.2 Operations by using operator in SFS . 13
5.3 Service transition by FNProxy strategy or FLM . 15
5.3.1 Description of FLM for FIB . 15
5.3.2 FNProxy strategy or FLM determining the service transition .15
5.4 Sequence diagram overview related to SFS . 16
5.4.1 General description of sequence diagram to SFS . 16
5.4.2 Main elements in the sequence diagram . 17
5.5 Narrative of AI dynamically enabling interaction . 18
5.5.1 General . 18
5.5.2 Dynamism caused by FNProxy link topology change . 19
5.5.3 Dynamism by driving the external environment .20
5.6 General framework of SFSP . .20
Annex A (informative) Representation reference of FNProxy collaboration effects .24
Annex B (informative) Bi-S operator Example between two FNProxies with C++.29
Annex C (informative) Methods for the domains .31
Annex D (informative) FNProxy Link Modes (FLMs) for SFS .33
Annex E (informative) Collaboration between FNQoS systems .35
Annex F (informative) Multi FNProxies making effect of dynamic MFHR .36
Annex G (informative) Avoiding SFS infinite transitions and overservice .37
Annex H (informative) General framework of FNQoS protocol .40
Bibliography .43
iii
© ISO/IEC 2023 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC
list of patent declarations received (see https://patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems.
A list of all parts in the ISO/IEC 21559 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
iv
© ISO/IEC 2023 – All rights reserved

Introduction
This document and ISO/IEC 21558-2 both pertain to the Future Network (FN), which is a broad concept
and has a wide application. The FNProxy technology introduced by ISO/IEC 21558-2 enables the
future network quality of service (FNQoS), which makes the FNQoS appear to be a mutual relationship
between intelligent FNProxies (i.e. harmonization between machines), not like the micro effect of
traditional QoS which depends on parameters.
The fact that FNProxy can promote the evolution of QoS to harmonize the process of networking. It
provides new forms of networking besides new concepts of QoS. This can lead to the emergence of new
industry trends in the field of systems interconnection technology.
This document specifies three engines (perception, negotiation and execution) to support the effective
work of FNProxy. This document also describes protocol mechanisms for synchronous interaction
between two FNProxies and among multiple FNProxies. Also, conditions and requirements for service
transitions between/among FNProxies are described. Annex A gives the quantitative calculation
method (harmonization between FNProxies) of interaction QoS effect, which can be used as a starting
point reference for developers to improve the calculation method.
Duo to the intelligence of FNProxy, synchronous interactions of Bidirectional Service (Bi-S) between
FNProxies have more extensive effects. Bi-S is necessary: a fundamental methodology, tool, and idea to
analyse and develop FNQoS systems.
This document explains in detail the protocol mechanisms of FNProxy interactions from two
perspectives: 1) the basic FNQoS system (BFS) 2) synthetic FNQoS system (SFS).
This document stipulates that protocol mechanisms can be used for all networks for transmission
purposes, and also for generalized networks, such as the implementation of semantic network protocol
mechanisms. The development of various network technologies based on Artificial Intelligence Enabled
Networking (AIEN) is recommended.
This document stipulates that the purpose of interactions between FNProxies can be either transmission
interactions or content interactions.
The protocol mechanism specified in this document is applicable to ISO/IEC TR 29181-8 and
ISO/IEC 21558-2.
The International Organization for Standardization (ISO) and the International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this document may
involve the use of a patent.
ISO and IEC take no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured ISO and IEC that he/she is willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this
respect, the statement of the holder of this patent right is registered with ISO and IEC. Information may
be obtained from the patent database available at www.iso.org/patents or https://patents.iec.ch.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights other than those in the patent database. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
v
© ISO/IEC 2023 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 21559-2:2023(E)
Telecommunications and information exchange between
systems — Future network protocols and mechanisms —
Part 2:
Proxy model-based quality of service
1 Scope
The concept of this document considers the FNQoS related to the FNProxy based in ISO/IEC TR 29181-8.
The protocol mechanism given in this document supports both the interaction between two FNProxies
of a basic FNQoS system (BFS) and the interaction among multiple FNProxies in a synthetic FNQoS
system (SFS).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 21558-2, Telecommunications and information exchange between systems — Future Network —
Architecture — Part 2: Proxy Model based Quality of Service
3 Terms, definitions and abbreviated terms
For the purposes of this document, the terms and definitions given in ISO/IEC 21558-2 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1 Terms and definitions
3.1.1
service transition
FNProxy transfers the requirements that it cannot serve to the corresponding FNProxy
Note 1 to entry: FNProxy service transition must be based on the FNProxy’s own strategy and real-time
information.
Note 2 to entry: That the direction of service transition can also be determined by the information of Bi-Ss
(FNProxy link pairs) stored in the FNProxy Interaction Bridge (FIB) (3.1.2) of the FNQoS system. By default, the
transition direction is based on the information stored in FIB.
© ISO/IEC 2023 – All rights reserved

3.1.2
FNProxy Interaction Bridge
FIB
linking path of two FNProxies in SFS
Note 1 to entry: It includes logical paths to realize the interactive exchange of information between any two
FNProxies in a synthetic FNQoS system (SFS) consisting of bidirectional service (Bi-S) pairs by cascading.
3.1.3
FNProxy Link Mode
FLM
FNProxy linking template
Note 1 to entry: It is used to normalizing the design, evaluation and calculation of binding, identification,
registration, management, bidirectional service (Bi-S) and negotiation for different styles of FNProxy link in a
synthetic FNQoS system (SFS).
Note 2 to entry: Several FLMs are listed in Annex D. When FLM is used by the designer, it means that the transition
direction of the FNProxy is not random but known in advance. The negotiation strategy (NS) of the FNProxy will
set the requirement type percepting function of the perception engine of FNProxy to sleep.
3.1.4
FNProxy Protocol Data Unit
FPDU
data unit needed by the interaction between two FNProxies in an FNQoS system
3.1.5
BFS Protocol
BFSP
set of FPDU fields, semantic changes and timing needed by all procedures supported by the two
FNProxies of BFS
3.1.6
SFS Protocol
SFSP
set of FPDU fields, semantic changes and time sequence of all procedures among all FNProxies in a SFS
3.1.7
FNProxy Strategy
FNPS
predetermined response of FNProxy
Note 1 to entry: It is for some important states or comprehensive effects of an FNQoS system based on the
environment of FNQoS system, the characteristics and capability of the FNProxy, the target of the FNProxy
owner and the real-time running status of the FNProxy.
Note 2 to entry: The FNProxy Strategy (response measures, scheme) and its solutions (sub schemes) are stored in
the FNProxy Strategy Base (FSB).
3.1.8
procedure
interaction sequence between FNProxies to complete the special tasks in the FNQoS system
Note 1 to entry: The comprehensive effect of FNQoS system consists of several procedures dynamically. It is
generally expressed in the form of a sequence diagram.
3.2 Abbreviated terms
AI Artificial Intelligence
AIEN Artificial Intelligence Enabled Networking
© ISO/IEC 2023 – All rights reserved

ALF Access Layer FNProxy
BFS Basic FNQoS System
BFSP BFS Protocol
Bi-S Bidirectional Service
BS Base Station
ES Execution Strategy
FIB FNProxy Interaction Bridge
FN Future Network
FPDU FNProxy Protocol Data Unit
FSB FNProxy Strategy Base
OSI Open System Interconnection
PDU Protocol Data Unit
QoS Quality of Service
SDO Standard Development Organization
SFS Synthetic FNQoS System
SFS SFS Protocol
UML Unified Modeling Language
4 Protocol mechanisms in BFS
4.1 Description of BFS
In engineering implementation, UML should be used to express a specific FNQoS system, so as to
improve the system's ability to adapt to FN. Attention should be paid to specific QoS requirement in FN
environment, and FNProxies should be extracted for dynamic interactivity.
Various FNProxies interactions based on the Bi-S mentioned in ISO/IEC 21558-2 are distributed in
an FNQoS system. When these dynamic service FNProxies constitute an FNQoS system, they can be
divided into BFS and SFS.
BFS is the smallest FNQoS system. There are only two FNProxies in BFS. Two FNProxies can interact
to form Bi-S. Its characteristics are: no matter whether there is Bi-S or not, when the two FNProxies
interact with each other, the FNProxies do not need to report the impact of FNProxies to the FNQoS
system, nor do they need to register or manage other operations.
The result of the interaction between two FNProxies is FHR. FHR is based on the technical
characteristics of Bi-S. See ISO/IEC 21558-2 for technical characteristics of Bi-S. See Annex A for the
quantitative method of FHR.
© ISO/IEC 2023 – All rights reserved

4.2 General interactive nature for FHR
4.2.1 FNProxy pairing situations
This subclause describes the fundamental mechanism of FNProxy interactions for generating FHR
based on Bi-S.
The interaction between each pair of FNProxies in the FNQoS system can contribute to the
comprehensive effect of FNQoS system. See Annex A for details. The contribution made by each pair
of FNProxy interaction to the comprehensive effect of FNQoS system depends on whether each pair of
FNProxies has both requirements and a service.
Figure 1 shows FNProxy A and FNProxy B in the FNQoS system. Both FNProxies can receive the
information from the other FNProxy, but their requirements cannot be matched by other appropriate
services, the two FNProxies not form a Bi-S. Either way, both FNProxies record and save each other's
management information.
The solid line indicates that FNProxy A sends a message to FNProxy B, and the dotted line indicates
that FNProxy B cannot feed back to FNProxy A according to its own situation. Figure 1 is the two quasi
interactive FNProxies without Bi-S.
Figure 1 — Two quasi interactive FNProxies without Bi-S
Figure 2 shows the successful pairing of FNProxy A and FNProxy B under the condition of Bi-S effect.
Figure 2 — Interaction FNProxy pairing success in FNQoS system
4.2.2 Active and passive functions of FNProxy
4.2.2.1 Active functions
When an FNProxy in an FNQoS system perceives the environment requirements and knows that it does
not have the capabilities to complete the requirements, it will forward the situation to other qualified
FNProxies according to its own strategy. The FNProxy's initiative is key. In this way it mimics the
natural abilities of humans (i.e. belief, desire and intention).
Other FNProxies receive the information and responded to this FNProxy according to its strategy.
4.2.2.2 Passive functions
In the interface of any FNProxy, the capability and method for other FNProxies to query this FNProxy
should be exposed. It is called the INQUIRY method.
4.2.3 Interaction model of BFS with engines
According to ISO/IEC 21558-2, there are three engines (perception, negotiation and execution) in any
FNProxy. If an AI algorithm is involved in the three-engine runtime, it can invoke the function of the
intelligence resource domain in ISO/IEC 21558-2 and usage strategy. Designers of FNQoS system are
not required to study complex AI algorithms when dealing with various FNQoS scenarios.
© ISO/IEC 2023 – All rights reserved

The application of AI algorithms should be perception first, then negotiation, and finally execution.
The three engines, which work in the following order, are the default configuration of the FNProxy: the
perception engine, the negotiation engine, and the execution engine. The process that three engines
execute in a sequence is called “the service cycle of FNProxy”.
Figure 3 shows a simplified FNProxy interaction model of BFS (two FNProxies are fnp1 and fnp2). Each
FNProxy contains the three engines to work together. Since there are only two FNProxies, the designer
will not consider the strategy of handling the transition, i.e. step c in the Figure 3 is represented by a
dotted line. When this figure is used to analyse SFS, i.e. when the number of interactive FNProxies is
more than or equal to three, FNProxies also transit services according to their execution strategy (ES).
There is also the strategy for FNProxy to generate a requirement. As shown in Figure 3, R1(ES1, E1),
R2(ES2, E2): the current execution value E1, E2 of FNProxy A1, FNProxy A2 is respectively converted
into the requirement value R1, R2 under execution strategy ES1, ES2.
I1 and I2 show the interference received by FNProxy A1 and A2 respectively.
C1 and C2 show the capability to represent A1 and A2 respectively.
RP1 represents the real-time preference perceived by FNProxy A1.
PS1 and PS2 represent the perception strategies of FNProxy 1 and FNProxy 2 respectively.
The three small black dots marked in FNProxy A2 in Figure 3 are called perception strategy (PS1),
negotiation strategy (NS1) and execution strategy (ES1). The strategy point indicates where the
strategy is placed by the developer. The interaction framework model of BFS in the Figure 3 can be
adapted to complex application scenarios.
© ISO/IEC 2023 – All rights reserved

Key
P Perceiving Engine
N Negotiating Engine
E Execution Engine
R Requirement of FNProxy
C Capability of FNProxy
I Interference received
RP Real-time preference perceived
PS Perceiving strategy
NS Negotiating strategy
ES Execution strategy
a
Judging whether FNProxy capability can meet the perceived requirements.
b
If the requirements can be met, it will be excuted.
c
If the requirements cannot be met, transit to another FNProxy based on negotiation strategy NS2.
d
After this requirement processing, continue to process the next requirements.
Figure 3 — Interaction model of BFS with three engine characteristics
4.2.4 FPDU definition of BFS
On the basis of traditional PDU, FPDU adds intelligent processing. The FNProxy senses the context
change of FPDU in real time, and the FNQoS system can change the networking strategy in real time.
Both the traditional communication network and AIEN are formed based on the interaction and
cooperation of FNProxies.
The service of one FNProxy processing the other in a pair of interactive FNProxies is not exactly the
same as the working service of OSI PDU processing between the lower layer and the upper. Many
fields of FPDU are obtained by this FNProxy, instead of being transferred from traditional inter-layer
processing. For example, target FNProxy number, this FNProxy requirements and FPDU style can be
obtained from the negotiation strategy, execution strategy, and domain name of this FNProxy. If the
requirements of this FNProxy cannot be perceived, there will be no FNProxy serving for this FNProxy.
Two FNProxies use BFS Protocol (BFSP) to interact.
© ISO/IEC 2023 – All rights reserved

Although there are various forms of FNs involved, FPDU (FNProxy Protocol Data Unit) can be composed
of the following basic fields, which can meet the needs of interaction between two FNProxies. The
designer of FNQoS application system can inherit and expand these basic fields according to the actual
situation. The basic fields of FPDU are: this (Source) FNProxy number, the target FNProxy number, type
of FPDU, requirements of this FNProxy and capability of this FNProxy, as shown below. It is abbreviated
as: FPDU {Sn, GN, FS, Cap, Req}. The designer of FNQoS application system can inherit and expand these
basic fields according to the actual situation.
FPDU
{
SourceNumber; /SN
GoalNumber; /GN
FPDUStyle; /FS
Capability; /Cap
Requirement; /Req
};
The semantics of the fields in FPDU are as follows:
Semantics of FPDU
{
SourceNumber: Source Number
/The value of this FNProxy's number
GoalNumber :Goal Number
/ In FNQoS systems with more than or equal to three FNProxes, the
goal number (GN) FNProxy of is generally consistent with the link
order of FLM. This is because the link order in FLM is fixed in advance.
FLM records the corresponding GN that can be transferred when the
FNProxy in the FNQoS system fails to sign a contract.
/ However, GN can also change in real time due to the following factors:
the corresponding procedure, the context content, the algorithm of the
special FNQoS system and the corresponding operators used.
FPDUStyle: FPDU Style
/When FPDUStyles are 0, 1, 2, 3 and 4, it means that FPDUStyles are
more suitable for management, operation, intelligence resource, user
and communication domains.
Capability: The FNProxy is given the maximum service capacity
/When the FNProxy provides services for multiple FNProxes, the per-
centage of the capability allocated to each requirement FNProxy can
be obtained according to the needs of the corresponding application
scenarios.
Requirement: Current Requirement of this FNProxy
© ISO/IEC 2023 – All rights reserved

/It refers to the requirements put forward by the FNProxy to other FN-
Proxy according to the contract value and the FNProxy's own strategy
before the FNProxy executes the new contract.
/ The type and size of the requirements proposed by the FNProxy vary
according to the execution value and execution strategy of the FNProxy.
};
The subfield and semantics of requirement field are as follows:
Requirement
{
Type/ Semantics is the type of requirement
/ Generally, the requirement type is not directly related to the FNProxy
characteristics. The requirement type of the FNProxy depends on the
effort of the owner of the FNProxy and the strategy for it.
Value / Semantics is the value of requirement
/Value can be expressed either abstractly or concretely. When the re-
quirement is abstract, the abstract expression can give the engineering
meaning result of specific technology according to the scene.
};
The subfield and semantics of capability field are as follows:
Capability
{
Type / Semantics is the type of capability
/Generally, the type of capability is directly related to the FNProxy's
characteristics, so that it can show the service capability of the FNProxy's
own characteristics.
Value/ Semantics is the value of capability
/Value can be expressed either abstractly or concretely. When the re-
quirement is abstract, the abstract expression can give the engineering
meaning result of specific technology according to the scene.
};
4.2.5 Strategy processing scheme in FNProxy
The FNProxy strategy is the action plan that the FNProxy needs in order to be stimulated by the change
when the state of the FNProxy in FNQoS system changes in the life cycle. The default important state is
the output value of the execution engine, but it also encourages designers to develop complex important
states composed of multiple factors and the action plan that FNProxy must respond to.
The execution engine of the FNProxy is affected by the FNProxy's own characteristics, capability,
FNProxy owner and other factors. Any FNProxy will respond to e1, e2 and en stimulation separately.
The response action plan is a sub strategy (scheme) that is pre-placed in the FNProxy strategy base
(FSB). The sub strategies are: scheme 1, scheme 2 and scheme n. As shown in Figure 4.
© ISO/IEC 2023 – All rights reserved

Figure 4 — Frame of strategy processing scheme in FNProxy
This FNProxy should be prepared by the designer in two ways: the first is the response measures sent
by the FNProxy to the paired FNProxy according to the execution amount after the FNProxy completes
the normal service execution. Pairing FNProxies treat their response value as their own perceived
requirements.
On the other hand, when the FNProxy fails to reach a contract through negotiation, the FNProxy transits
the unfinished service to another FNProxy selected according to its own situation.
4.2.6 Concept of the procedures in BFS
The concept of service effect of BFS can be understood as the sum of all the service procedures that
are customized to solve various requirements based on the interaction between two FNProxies, i.e.
the effect of FNQoS system is shown by all procedures, and each procedure includes a specific list of
FNProxy sequential messages as follows:
FNQoS system = {Procedure list}
Procedure = {Sequential message list}
Although there are only two FNProxies in BFS, when the purpose and effect of the procedures supported
by the two FNProxies are different, the interaction protocols between the two FNProxies are generally
different. No matter what kind of purpose and effect of procedure in BFS, the protocol of FNProxy
interaction in BFS should include three elements: the change of execution dynamic state of procedures
(i.e. the so-called timing), the FPDU and its semantic change.
For example, in two procedures in BFS, such as the procedure of "start an FNProxy" and the procedure
of "query an FNProxy", the FPDUstyle fields of the FPDU can be "M" (Management) and "O" (Operation)
respectively. In addition, the FPDU of "start an FNProxy" procedure does not need extended fields, while
the FPDU of "query an FNProxy" procedure needs extended fields (see special_FPDU in 5.6) to indicate
that the query method is "INQUIRE", and the primitives and messages involved can be as follows:
Primitive:
Query (result, GN, Method)
Result: all methods and their functions of GN
GN: GoalNumber
Method: INQUIRE
© ISO/IEC 2023 – All rights reserved

Message (Query)
{
“Method”: “INQUIRE”
}
The semantics of the field "Method" is to use the public method "INQUIRE" of FNProxy GN. The public
method can let the opposite FNProxy understand its own methods and capabilities.
After starting, the FNProxy can send a request message to query the other party at any time. In this
way, all the methods and capabilities of the other party are known at any time.
Query (GN, INQUIRE);
There are four kinds of basic procedures in the BFS in Figure 5, Figure 6, Figure 7 and Figure 8. The
primitives and messages that be involved are the following:
Procedure 1: The two FNProxies start individually
Primitive 1: Init (FNP owner’s Initial value)
Message 1 (Init)
{
“Method”: “initialize”
}
Figure 5 — Procedure started by two FNProxies independently
Procedure 2: One awakens the other
Primitive 2:
INIT (FNP owner’s Initial value)
WAKE_FNPROXY (SN, GN)
Message 2 (INIT, WAKE_FNPROXY)
{
“Method”: “initialize”, “request”
© ISO/IEC 2023 – All rights reserved

}
Figure 6 — Waking up the other party's procedureProcedure 3: Stopping FNProxy service from
working
Primitive 3:
STOP (GN)
UPDATE (GN, SN)
Message 3 (STOP, UPDATE)
{
“Method”: “Stop”, “Update”
}
Figure 7 — Procedure of stopping FNProxy serviece
Procedure 4: Calculating harmony degree
Primitive 4:
HARMONY_DEGREE (result, FNP1, FNP2)
Result: Harmony degree
© ISO/IEC 2023 – All rights reserved

FNP1: FNP1’s information
FNP2: FNP2’s information
Message 4 (HARMONY_DEGREE)
{
“Method”: “Calculating”
}
Figure 8 — Procedure of calculating the harmony value of SFS
4.2.7 Function invoke descriptions to domains of FNQoS system
The FNProxy should invoke the functions of the six functional domains (see ISO/IEC 21558-2)
distributed in the FNQoS system. Generally, the functions of these three domains (management,
operation and intelligent resources domain) are frequently-used functions supporting the FNQoS
system in most cases. Some functions of these three domains are listed in Annex C for reference.
The FNProxy includes three engines that can work together: the perception engine, negotiation engine
and the execution engine. Each engine of each FNProxy in the FNQoS system will use the functions in
six domains in real time according to the FNProxy strategies and requirements.
In an FNQoS system, the cooperation mechanism among the engines in all FNProxies should be the
same. When the three engines work, each engine in the FNProxy works according to the received
information, combined with the FNProxy capabilities and strategies.
The intelligence level of FNProxies should depend on the intelligence level of the function of the
intelligent resource domain. If the FNProxy can access the intelligent resources in the cloud through the
application network (such as the Internet) realized by the communication domain function.
5 Protocol mechanisms in SFS
5.1 Description of SFS
The mechanism of multi FNProxy interaction protocol in BFS is based on the interaction mechanism
between two FNProxies in SFS.
© ISO/IEC 2023 – All rights reserved

SFS means that there are more than or equal to 3 FNProxies in the FNQoS system. Its characteristics
are: there be multiple Bi-S pairs, and the FNProxy needs to report its information to the SFS.
When the SFS is composed of a mixture of FLMs as shown in Annex D, it is necessary to implement the
link path between any two FNProxies. The FLMs in Annex D are used to service transition path fixed
when service is not meet.
No matter how the SFS is implemented whether with central or distributed computation, designers
should set the maximum number of FNPoxies in SFS by combining the characteristics of FNPoxies and
calculating the memory size of nodes. In addition, the fixed FNProxy links of FLM should be used to
achieve multi-FNProxy harmony (MFHR). As long as the value of MFHR is high, the service transition
and information update time would be reduced in SFS.
5.2 Operations by using operator in SFS
In the SFS, the interaction mechanism becomes complicated due to the increase of the number of
FNProxy pairs. In this case, the effect of improving the specific target achieved by the SFS will be better
than that of the BFS. This constitutes the MFHR. MFHR is realized by multiple FNProxies with the help
of those FLMs of FIB. FIB is a logical path or channel to realize the interactive exchange of information
between FNProxies in SFS. As shown in Figure 9. The component software or hardware that can support
the interaction of multiple FNProxies can be regarded as the bridge between related FNProxies. The
software or hardware of this component is implemented based an FNProxy. If there is no link for these
FNProxies, the FIB does not exist.
Figure 9 — Synthetic FNQoS system (SFS) with FIB
In order to facilitate the unification of the design and evaluation methods of various SFS, the links
among FNProxies should be solidified into some special FLMs, as shown in Annex D.
The basis of multiple FNProxy interactions is that a single Bi-S can support a pair of FNProxies
interactions and the Bi-S technical characteristics. Based on Bi-S, FNProxies in SFS can interact
synchronously.
The analysis to FIB should at least include:
a) The dynamic/fixed interaction mechanism of FIB through FNProxies, i.e.,the interaction between
FNProxies supported by multiple Bi-S pairs.
b) The method of FNProxy operating FIB, that should adopt modular idea and be realized by operators.
Analyse the universal interaction model or abstract operation symbol of calculation between FNProxies,
as shown in Figure 10.
© ISO/IEC 2023 – All rights reserved

Figure 10 — FNProxy Interaction Bridge (FIB) among multi-FNProxies
For example, when negotiating between FNProxy 1 and FNProxy 3 in Figure 10, the following
comprehensible formal mathematical operator (see ISO/IEC 21558-2) can be expressed (the designer
can focus on developing operation process of the negotiator to reduce the complexity of the FNQoS
system and its development costs):
(FNProxy 1) Operator (FNProxy 3) evolute to:
(FNProxy 1) Negotiator (FNProxy 3)
Similarly, in the FNQoS system, the binding, identification, registration, and Bi-S operations between
any FNProxy A and any FNProxy B, even FNProxy A operating on itself can also be written as follows:
— (FNProxy A) Binder (FNProxy B)
— (FNProxy A) Identifier (FNProxy B)
— (FNProxy A) Registry (FNProxy B)
— (FNProxy A) Bi-S (FNProxy B)
— Self-Operator (FNProxy A)
The basic calculation meaning of operators Bi-S, binder, identifier and registry should be as follows:
— Bi-S: "(FNProxy A) Bi-S (FNProxy B)" refers to comparing the type and size between FNProxy A and
FNProxy B respectively.
For example, the result of the operator can be defined as the enumerator {(0, 0), (0, 1), (1, 0), (1, 1)}.
When the formula "(FNProxy A) Bi-S (FNProxy B)" is operated, if the value of the formula is (0, 1),
then it means that FNProxy A has no ability to serve FNProxy B, but FNProxy B has the ability to
serve FNProxy A.
— "(FNProxy A) Binder (FNProxy B)" refers to both FNProxy A and FNProxy B have fixed service
requirements, that is: they do not participate in the possible dynamic service transition activities in
dynamic perception in the SFS.
— Identifier: (FNProxy A) Identifier (FNProxy B) refers to the technical process of identity
determination between FNProxy A and FNProxy B. The calculation result of this operator is the
current information and state of the two FNProxes if the identities of both parties are proved to be
valid.
© ISO/IEC 2023 – All rights reserved

— Registry: (FNProxy A) Registry (FNProxy B) refers to two parties registering their own information
with each other in the case of no central FNProxy in SFS.
— Negotiator: (FNProxy A) Negotiator (FNProxy B) refers to the operator in which two FNProxes sign
contracts with each other according to their own strategies after Bi-S operation in SFS.
— Self-Operator: Self-Operator (FNProxy A) refers to each FNProxy has its own process of variation.
The actual meaning and application effect of each operator can be customized according to the actual
needs of the specific FNQoS system. BFSP is used in operator operation. See Annex B.
For Bi-S operators, such as for hybrid FLMs in FNQoS systems, the link path between any two FNProxies
are implicitly established during the transition of FNProxy to the next FNProxy. Figure 11 shows the
process of three consecutive transitions (A->B, B->C and C->D). Once the FNQoS system is running, any
two FNProxies (for example, FNProxy A and FNProxy D) have implicitly realized the operation effect of
three transitions in “A Bi-S D”. If necessary, special management software can be designed to extract
the link path (A -> B -> C -> D) through multiple FNProxies in FLB.
Operation effect of ā A Bi-S DĂ above Equal to theā A Bi-S BĂ, ā B Bi-S CĂ and ā C Bi-s DĂ below
Figure 11 — Path of FIB linked by Bi-Ss under multi-FNProxy
5.3 Service transition by FNProxy strategy or FLM
5.3.1 Description of FLM for FIB
There are three FLMs specified: centralized, fully distributed, and hierarchical modes, which can
choose to use when implementing a particular FNQoS system, as shown in Annex D. People can develop
FLB technical documents based on but not limited to the three FLMs in Annex D that can be used by
developers for their own FNQoS systems.
The SFS should record the necessary information of the FLM, including the type, structure, and the
number of real-time FNProxies of the FLM, as well as the detailed log of each FNProxy's work. The log
contents include any FNProxy in the FNQoS system, the necessary state information of all activities
from activation (from start-FNQoS system to stop the FNQoS system). This state information should
include service transition paths and changing history of requirements (services).
5.3.2 FNProxy strategy or FLM determining the service transition
Any FNProxy in SFS needs other FNProxy’s services on its FLM: Any FNProxy of the SFS in Figure 12 has
the same work principle and steps. For example, FNProxy A1 includes the following steps: the perception
engine P1 in FNProxy A1 processes the received real-time interference I1 and real-time preference RP1,
then after the processing of negotiation engine N1 and execution engine E1, FNProxy A1 generates the
requirement R1 of FNProxy A1 according to the execution value E1 and strategy S1. The meaning of
FNProxy personification is: FNProxy A1's E1 means that FNProxy A1 has paid consumption or expense
for E1; FNProxy A1 hopes to get a reward for R1.
© ISO/IEC 2023 – All rights reserved

Which FNProxy in FLM serves the requirement R1 generated by FNProxy A1 in SFS depends not only on
the above steps of generating R1, but also on the FLM adopted by FNQoS system.
As shown in the dotted line with arrow on the left from R1 to P2 in Figure 12, the type of requirement
R1 is consistent with the type of capability of FNProxy A2, i.e. FNProxy A2 serves FNProxy A1. Since P1
of FNProxy A1 is R2 of FNProxy A2, both FNProxy A2 and FNProxy A1 serve each other. This constitutes
the Bi-S case. The service effect or harmony degree between FNProxy A2 and FNProxy A1 with Bi-S is
higher tha
...