ISO/IEC 21559-2:2023
(Main)Telecommunications and information exchange between systems — Future network protocols and mechanisms — Part 2: Proxy model-based quality of service
Telecommunications and information exchange between systems — Future network protocols and mechanisms — Part 2: Proxy model-based quality of service
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).
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
General Information
Standards Content (Sample)
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 21559-2:2023(E)
© ISO/IEC 2023
---------------------- Page: 1 ----------------------
ISO/IEC 21559-2:2023(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
ISO/IEC 21559-2:2023(E)
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
---------------------- Page: 3 ----------------------
ISO/IEC 21559-2:2023(E)
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
---------------------- Page: 4 ----------------------
ISO/IEC 21559-2:2023(E)
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
---------------------- Page: 5 ----------------------
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.
1
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC 21559-2:2023(E)
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
2
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 21559-2:2023(E)
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.
3
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC 21559-2:2023(E)
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.
4
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 21559-2:2023(E)
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.
5
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC 21559-2:2023(E)
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.
6
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 21559-2:2023(E)
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
7
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC 21559-2:2023(E)
/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 enginee
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.