Etat de l'art
This commit is contained in:
Leopold Clement
parent
9119b3e2bc
commit
600d9a86fa
15 changed files with 683 additions and 23 deletions
5
.gitignore
vendored
5
.gitignore
vendored
|
|
@ -284,3 +284,8 @@ TSWLatexianTemp*
|
|||
# Uncomment the next line to have this generated file ignored.
|
||||
#*Notes.bib
|
||||
|
||||
*.ist
|
||||
*.glo
|
||||
puml/*.png
|
||||
puml/*.svg
|
||||
pdf_img/*
|
||||
|
|
|
|||
23
makefile
23
makefile
|
|
@ -1,24 +1,21 @@
|
|||
FIGURES_SVG=$(wildcard raw_img/*.svg)
|
||||
FIGURES_PDF=$(subst raw_img/,pdf_img/,$(FIGURES_SVG:.svg=.pdf_tex))
|
||||
|
||||
all : rapport.tex rapport.bib $(FIGURES_PDF)
|
||||
all : rapport.tex rapport.bib $(FIGURES_PDF) $(UML_PNG) png_img/gain_action.png
|
||||
plantuml -checkmetadata puml
|
||||
lualatex -shell-escape rapport.tex
|
||||
bibtex rapport
|
||||
makeglossaries rapport
|
||||
lualatex -shell-escape rapport.tex
|
||||
lualatex -shell-escape rapport.tex
|
||||
|
||||
clean :
|
||||
rm -f rapport.aux
|
||||
rm -f rapport.bbl
|
||||
rm -f rapport.blg
|
||||
rm -f rapport.out
|
||||
rm -f rapport.log
|
||||
rm -f rapport.pdf
|
||||
rm -f rapport.toc
|
||||
rm -f rapport.lof
|
||||
rm -f rapport.lot
|
||||
png_img/gain_action.png :
|
||||
python3 png_img/gen_fig_g.py
|
||||
|
||||
clean : clean-latex
|
||||
rm -f -r pdf_img/
|
||||
rm -f -r puml/*.svg
|
||||
rm -f -r puml/*.png
|
||||
|
||||
clean-latex :
|
||||
rm -f rapport.aux
|
||||
|
|
@ -30,6 +27,10 @@ clean-latex :
|
|||
rm -f rapport.toc
|
||||
rm -f rapport.lof
|
||||
rm -f rapport.lot
|
||||
rm -f rapport.ist
|
||||
rm -f rapport.glg
|
||||
rm -f rapport.gls
|
||||
rm -f rapport.glo
|
||||
|
||||
pdf_img/%.pdf : raw_img/%.svg pdf_img/%.pdf_tex
|
||||
inkscape -D -z --file=$< --export-pdf=$@ --export-latex
|
||||
|
|
|
|||
BIN
png_img/comp_tcp_Xiao.png
Normal file
BIN
png_img/comp_tcp_Xiao.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 110 KiB |
12
png_img/gen_fig_g.py
Normal file
12
png_img/gen_fig_g.py
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
import numpy as np
|
||||
import matplotlib.pyplot as plt
|
||||
|
||||
fig, ax = plt.subplots(1, 1)
|
||||
a = np.linspace(-10, 10, 1000)
|
||||
g = (1+a)*(a>=0) + 1/(1-a)*(a<0)
|
||||
ax.plot(a, np.log(g))
|
||||
ax.set_xlabel('$a _ t ^ {\\left( i \\right)}}$')
|
||||
ax.set_ylabel('$ln \\left( \\frac{c _ {t+1} ^ {\\left( i \\right) } }{c _ t ^ {\\left( i \\right)}} \\right)$')
|
||||
ax.grid()
|
||||
fig.tight_layout()
|
||||
fig.savefig('png_img/gain_action.png')
|
||||
67
puml/call_stack_envoie.puml
Normal file
67
puml/call_stack_envoie.puml
Normal file
|
|
@ -0,0 +1,67 @@
|
|||
@startuml
|
||||
skinparam roundcorner 20
|
||||
skinparam sequenceMessageAlign direction
|
||||
hide footbox
|
||||
|
||||
actor User as usr order 1
|
||||
|
||||
box "CoAPthon"
|
||||
queue HelperClient.queue <<atribut>> order 19
|
||||
participant HelperClient.get <<methode>> order 10
|
||||
participant HelperClient.send_request <<methode>> order 11
|
||||
|
||||
participant CoapClient.send_message <<methode>> order 21
|
||||
participant CoapClient.send_datagram <<methode>> order 22
|
||||
participant CoapClient._start_retransmission <<thread>> order 31
|
||||
participant CoapClient._receiver_thread <<thread>> order 32
|
||||
participant CoapClient._retransmit <<thread>> order 33
|
||||
|
||||
end box
|
||||
|
||||
box "Module IA"
|
||||
participant SuperviseurLocal.RTO <<atribut>> order 41
|
||||
participant SuperviseurLocal.envoie_token <<methode>> order 42
|
||||
participant SuperviseurLocal.reception_token <<methode>> order 43
|
||||
end box
|
||||
boundary reseau order 51
|
||||
|
||||
usr -> HelperClient.get ++: .get(path)
|
||||
HelperClient.get -> HelperClient.get : generate_random_token(2)
|
||||
HelperClient.get -> HelperClient.send_request ++: send_request(request)
|
||||
HelperClient.send_request -> CoapClient.send_message ++: send_message(request)
|
||||
CoapClient.send_message -> CoapClient.send_datagram ++: send_datagram(request)
|
||||
|
||||
CoapClient.send_datagram -> reseau : datagram
|
||||
CoapClient.send_datagram -> SuperviseurLocal.envoie_token : envoie(token)
|
||||
CoapClient.send_datagram -> CoapClient._receiver_thread ++#red: Thread.start()
|
||||
|
||||
CoapClient.send_datagram --> CoapClient.send_message --: None
|
||||
CoapClient.send_message -> CoapClient._start_retransmission ++#Blue: Thread.start()
|
||||
CoapClient.send_message --> HelperClient.send_request --: None
|
||||
HelperClient.send_request -> HelperClient.queue : wait for
|
||||
|
||||
CoapClient._start_retransmission -> SuperviseurLocal.RTO ++#Blue: RTO ?
|
||||
return RTO
|
||||
|
||||
CoapClient._start_retransmission -> CoapClient._retransmit --++#Green: Thread.start()
|
||||
|
||||
loop Pas de réponse sur le socket UDP avant l'expiration du RTO
|
||||
...Attente...
|
||||
CoapClient._retransmit -> CoapClient._retransmit : retransmit_count += 1
|
||||
CoapClient._retransmit -> CoapClient._retransmit : RTO *= 2
|
||||
CoapClient._retransmit -> CoapClient.send_datagram ++#Green: send_datagram(request)
|
||||
CoapClient.send_datagram -> reseau : datagram
|
||||
CoapClient.send_datagram -> SuperviseurLocal.envoie_token : envoie(token)
|
||||
return None
|
||||
end
|
||||
|
||||
reseau --> CoapClient._receiver_thread : datagram
|
||||
CoapClient._receiver_thread -> SuperviseurLocal.reception_token : reception(token)
|
||||
CoapClient._receiver_thread -> CoapClient._retransmit !!: wait for the thread end
|
||||
CoapClient._receiver_thread -> HelperClient.queue --: response
|
||||
|
||||
HelperClient.queue --> HelperClient.send_request : response
|
||||
HelperClient.send_request --> HelperClient.get --: response
|
||||
HelperClient.get --> usr --: response
|
||||
|
||||
@enduml
|
||||
24
puml/cas_utilisation_coap.puml
Normal file
24
puml/cas_utilisation_coap.puml
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
@startuml
|
||||
|
||||
hide footbox
|
||||
participant Capteur as capt
|
||||
database Cloud as cld
|
||||
|
||||
[-> capt ++: activation exterieur\ntimer, interuption...
|
||||
capt -> cld : CON[0x77]\nPUT/url?val
|
||||
cld --> capt !!: ACK[0x77]
|
||||
|
||||
newpage
|
||||
|
||||
cld -> capt ++: CON[0x45]\nGET/URL
|
||||
capt --> cld --: ACK[0x45]\nval
|
||||
|
||||
newpage
|
||||
|
||||
cld -> capt ++: CON[0x45]\nGET/URL
|
||||
{start} capt --> cld : ACK[0x45]
|
||||
{end} capt -> cld : CON[0xdc]\nval
|
||||
{start} <-> {end} : determination de val
|
||||
cld --> capt !!: ACK[0xdc]
|
||||
|
||||
@enduml
|
||||
64
puml/struc_centrale.puml
Normal file
64
puml/struc_centrale.puml
Normal file
|
|
@ -0,0 +1,64 @@
|
|||
@startuml
|
||||
:Utilisateur: as usr
|
||||
database "Base de\ndonnée" as db
|
||||
file "UDP" <<lib>> as udp
|
||||
file "TensorFlow" <<lib>> as tf
|
||||
file "Keras" <<lib>> as keras
|
||||
|
||||
package "Client CoAP" as global {
|
||||
component "Superviseur" as super <<Thread>>{
|
||||
() "Interface CoAP" as h_coap
|
||||
() "Collecteur donnée" as h_stat
|
||||
|
||||
component "Gestionaire\nglobal" <<main>> as main_super
|
||||
component "Statisticien" as stat
|
||||
|
||||
stack "buffer\nd'experience" as buff
|
||||
[NN]
|
||||
[optimiseur]
|
||||
[horloge] <<interuption>>
|
||||
|
||||
h_coap -- main_super
|
||||
|
||||
buff --> optimiseur : expérience
|
||||
optimiseur --> NN : met à jour
|
||||
horloge --> optimiseur : déclanche
|
||||
|
||||
h_stat - stat
|
||||
stat -> buff : remplis
|
||||
}
|
||||
component "Session" as client <<Threads>> {
|
||||
() "Socket UDP" as s_udp
|
||||
() "Session handle" as h_session_message
|
||||
() "RTO" as h_session_rto
|
||||
queue "Buffer" as file_attente
|
||||
[Gestionaire\nde la session] <<main>> as main_sess
|
||||
[timer] <<interuption>> as timer
|
||||
h_session_message -- main_sess
|
||||
h_session_rto -- main_sess
|
||||
main_sess --> s_udp : packet\nudp
|
||||
main_sess ..> file_attente : use
|
||||
main_sess <-- s_udp : aquitement\n&\nréponse
|
||||
main_sess ..> timer : use
|
||||
}
|
||||
|
||||
main_super --( h_session_message
|
||||
NN --( h_session_rto
|
||||
main_sess --( h_stat
|
||||
|
||||
note top of client
|
||||
Un par capteur
|
||||
end note
|
||||
}
|
||||
|
||||
usr --( h_coap
|
||||
db --( h_coap
|
||||
|
||||
|
||||
buff ..> tf : use
|
||||
optimiseur ..> tf : use
|
||||
NN ..> keras : use
|
||||
s_udp ..> udp : use
|
||||
|
||||
|
||||
@enduml
|
||||
35
puml/structure_1.puml
Normal file
35
puml/structure_1.puml
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
@startuml
|
||||
:utilisateur: as usr
|
||||
[UDP] <<lib>> as udp
|
||||
[Controleur global] as chef
|
||||
package "Client COAP" <<Instance>> as coap{
|
||||
[parseur] as parseur
|
||||
[lexeur] as lexeur
|
||||
() "socket udp" as s_udp
|
||||
() "handle coap" as h_coap
|
||||
package "Gestion des retransmisions" as retransmition{
|
||||
[gestionaire] as gestionaire
|
||||
[timer] as timer
|
||||
database "Liste des\nmessages" as db_msg
|
||||
}
|
||||
}
|
||||
|
||||
lexeur --> s_udp : message NCON
|
||||
lexeur --> gestionaire : message CON
|
||||
s_udp --> parseur : message reçu
|
||||
|
||||
gestionaire ..> timer : use
|
||||
gestionaire ..> db_msg : use
|
||||
gestionaire -> s_udp : émition et\nretransmition
|
||||
|
||||
parseur --> gestionaire : Tokken
|
||||
|
||||
s_udp ..> udp : use
|
||||
|
||||
usr --( h_coap
|
||||
h_coap -> lexeur : requette
|
||||
h_coap <- parseur : reponse
|
||||
gestionaire --> chef : info local
|
||||
chef --> gestionaire : info global
|
||||
|
||||
@enduml
|
||||
62
puml/structure_2.puml
Normal file
62
puml/structure_2.puml
Normal file
|
|
@ -0,0 +1,62 @@
|
|||
@startuml
|
||||
file "Client Coap" as global{
|
||||
component "Superviseur" as super
|
||||
|
||||
[Parseur] <<function>> as par
|
||||
[Lexeur] <<function>> as lex
|
||||
|
||||
component "Session" <<Thread>> as session {
|
||||
() "Socket UDP" as s_udp
|
||||
() "Session handle" as h_session
|
||||
queue "Buffer" as file_attente
|
||||
[Gestionaire\nde la session] <<main>> as main_sess
|
||||
h_session - main_sess
|
||||
|
||||
file_attente <. main_sess : use
|
||||
|
||||
component "Communication" <<Thread>> as th_com{
|
||||
[timer]
|
||||
[Gestionaire\ndu message] <<main>> as main_msg
|
||||
main_msg ..> timer : use
|
||||
main_msg --> s_udp : packet udp
|
||||
main_msg <-- s_udp : aquitement\n&\nréponse
|
||||
}
|
||||
|
||||
component "Apprentissage" <<Thread>> as th_appr{
|
||||
stack "buffer\nd'experience" as buff
|
||||
[NN]
|
||||
[optimiseur]
|
||||
[horloge] <<interuption>>
|
||||
|
||||
buff -down-> optimiseur : expérience
|
||||
optimiseur -down-> NN : met à jour
|
||||
horloge -> optimiseur : déclanche
|
||||
}
|
||||
|
||||
main_sess ..> th_com : Instancie
|
||||
main_sess --> main_msg : Requette\n&\nRTO
|
||||
main_msg --> main_sess : Réponse\n&\ninfo liaison
|
||||
|
||||
main_sess --> buff : transition
|
||||
main_sess ..> NN : use
|
||||
|
||||
note left of th_com
|
||||
Une instance par message
|
||||
end note
|
||||
}
|
||||
note left of session
|
||||
Une instance par capteur
|
||||
end note
|
||||
|
||||
}
|
||||
|
||||
file "UDP" <<lib>> as lib_udp
|
||||
file "Tensorflow\nKeras" <<Module>> as lib_ia
|
||||
main_msg ..> par : use
|
||||
main_msg ..> lex : use
|
||||
s_udp .down.> lib_udp : use
|
||||
th_appr .down.> lib_ia : use
|
||||
|
||||
:acteur:
|
||||
acteur --( h_session
|
||||
@enduml
|
||||
32
puml/temporal_transaction_invalide.puml
Normal file
32
puml/temporal_transaction_invalide.puml
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
@startuml
|
||||
concise "Cloud" as cld
|
||||
concise "Capteur" as capt
|
||||
|
||||
cld is "idle"
|
||||
capt is "idle"
|
||||
|
||||
@0 as :emition_req
|
||||
cld -> capt@+15 : "GET"
|
||||
cld is "waiting\nRTO 1"
|
||||
|
||||
@+15 as :reception_req
|
||||
capt is "traitement"
|
||||
|
||||
@+5 as :emition_rep
|
||||
capt -> cld@+15 : "200"
|
||||
capt is "idle"
|
||||
|
||||
@+10
|
||||
cld is "waiting\nRTO 2"
|
||||
cld -> capt@+15 : "GET"
|
||||
|
||||
@+5 as :reception_rep
|
||||
cld is "traitement"
|
||||
|
||||
@capt
|
||||
@30 <-> @35 : rtt
|
||||
@cld
|
||||
@0 <-> @30 : rto
|
||||
|
||||
|
||||
@enduml
|
||||
27
puml/temporal_transaction_valide.puml
Normal file
27
puml/temporal_transaction_valide.puml
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
@startuml
|
||||
concise "Cloud" as cld
|
||||
concise "Capteur" as capt
|
||||
|
||||
cld is "idle"
|
||||
capt is "idle"
|
||||
|
||||
@0 as :emition_req
|
||||
cld -> capt@+10 : "GET"
|
||||
cld is "waiting RTO 1"
|
||||
|
||||
@+10 as :reception_req
|
||||
capt is "traitement"
|
||||
|
||||
@+5 as :emition_rep
|
||||
capt -> cld@+10 : "200"
|
||||
capt is "idle"
|
||||
|
||||
@+10 as :reception_rep
|
||||
cld is "traitement"
|
||||
|
||||
@capt
|
||||
@0 <-> @25 : rtt
|
||||
@cld
|
||||
@0 <-> @30 : rto
|
||||
|
||||
@enduml
|
||||
47
puml/utilisation_classique_apprentissage.puml
Normal file
47
puml/utilisation_classique_apprentissage.puml
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
@startuml
|
||||
database DB as db
|
||||
|
||||
box "Superviseur COAP"
|
||||
participant "Optimiseur" as opti
|
||||
participant "Réseau de\nneurrones" as NN
|
||||
participant "Buffer\nd'expérience" as buffer
|
||||
participant "Statisticien" as stat
|
||||
end box
|
||||
|
||||
box "Client COAP"
|
||||
boundary "Handle CoAP" as h_coap
|
||||
queue "File d'attente" as file
|
||||
participant "Gestionaire des\nretransmitions" as gest
|
||||
boundary "UDP socket" as udp
|
||||
end box
|
||||
|
||||
boundary "reseau de\ncapteurs" as capt
|
||||
|
||||
-> db ++: déclanchement
|
||||
|
||||
db -> h_coap ++: requète : URI
|
||||
h_coap -> file : requète : URI
|
||||
hnote over file
|
||||
On attend qu'il n'y ais plus
|
||||
de message non-aquitée pour
|
||||
ce capteur
|
||||
endnote
|
||||
file -> gest ++: requète : URI
|
||||
group while [non réussite]
|
||||
gest -> udp ++: CON[akc_token]\nGET/URI(req_token)
|
||||
udp -> capt ++: CON[akc_token]\nGET/URI(req_token)
|
||||
alt réussite
|
||||
return AKC[akc_token]\nval(req_token+1)
|
||||
return AKC[akc_token]\nval(req_token+1)
|
||||
|
||||
else timeout
|
||||
gest-> gest : doublement RTO
|
||||
end
|
||||
end
|
||||
gest -> stat : n_retransmition, RTT
|
||||
gest -> h_coap --: réponse : val
|
||||
return réponse : val
|
||||
deactivate db
|
||||
|
||||
|
||||
@enduml
|
||||
39
puml/utilisation_classique_transmition.puml
Normal file
39
puml/utilisation_classique_transmition.puml
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
@startuml
|
||||
database DB as db
|
||||
|
||||
box "Superviseur COAP"
|
||||
participant "Optimiseur" as opti
|
||||
participant "Réseau de\nneurrones" as NN
|
||||
participant "Buffer\nd'expérience" as buffer
|
||||
participant "Statisticien" as stat
|
||||
end box
|
||||
|
||||
box "Client COAP"
|
||||
boundary "Handle CoAP" as h_coap
|
||||
queue "File d'attente" as file
|
||||
participant "Gestionaire des\nretransmitions" as gest
|
||||
boundary "UDP socket" as udp
|
||||
end box
|
||||
|
||||
boundary "reseau de\ncapteurs" as capt
|
||||
|
||||
|
||||
|
||||
group while [true]
|
||||
-> opti ++: déclanchement périodique
|
||||
buffer -> opti : expérience
|
||||
NN -> opti : état du NN
|
||||
opti -> opti : optimisation du NN
|
||||
opti -> NN --: nouveaux poids
|
||||
|
||||
loop (i=0; i<1000; i++)
|
||||
-> stat ++: déclanchement périodique
|
||||
stat -> buffer : nouvelle transition
|
||||
stat -> NN --: nouvel état
|
||||
NN -> gest --: nouveau RTO
|
||||
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
@enduml
|
||||
22
rapport.bib
22
rapport.bib
|
|
@ -8,7 +8,7 @@
|
|||
issn = {1913-3715, 1913-3723},
|
||||
doi = {10.4236/ijcns.2011.48060},
|
||||
file = {/home/leopold/snap/zotero-snap/common/Zotero/storage/H8M4DAE6/Ahmed et Mohamed - 2011 - Fairness Aware Group Proportional Frequency Domain.pdf},
|
||||
journal = {International Journal of Communications, Network and System Sciences},
|
||||
journal = {IJCNS},
|
||||
number = {08}
|
||||
}
|
||||
|
||||
|
|
@ -215,7 +215,7 @@
|
|||
doi = {10.1109/TNSE.2018.2835758},
|
||||
abstract = {Next generation network access technologies and Internet applications have increased the challenge of providing satisfactory quality of experience for users with traditional congestion control protocols. Efforts on optimizing the performance of TCP by modifying the core congestion control method depending on specific network architectures or apps do not generalize well under a wide range of network scenarios. This limitation arises from the rule-based design principle, where the performance is linked to a pre-decided mapping between the observed state of the network to the corresponding actions. Therefore, these protocols are unable to adapt their behavior in new environments or learn from experience for better performance. We address this problem by integrating a reinforcement-based Q-learning framework with TCP design in our approach called QTCP. QTCP enables senders to gradually learn the optimal congestion control policy in an on-line manner. QTCP does not need hard-coded rules, and can therefore generalize to a variety of different networking scenarios. Moreover, we develop a generalized Kanerva coding function approximation algorithm, which reduces the computation complexity of value functions and the searchable size of the state space. We show that QTCP outperforms the traditional rule-based TCP by providing 59.5\% higher throughput while maintaining low transmission latency.},
|
||||
file = {/home/leopold/snap/zotero-snap/common/Zotero/storage/DBTMF6SI/Li et al. - 2019 - QTCP Adaptive Congestion Control with Reinforceme.pdf},
|
||||
journal = {IEEE Transactions on Network Science and Engineering},
|
||||
journal = {IEEE Trans. Netw. Sci. Eng.},
|
||||
language = {en},
|
||||
number = {3}
|
||||
}
|
||||
|
|
@ -280,6 +280,18 @@
|
|||
journal = {International Journal of Big Data Intelligence}
|
||||
}
|
||||
|
||||
@techreport{rheeCUBICFastLongDistance2018,
|
||||
title = {{{CUBIC}} for {{Fast Long}}-{{Distance Networks}}},
|
||||
author = {Rhee, I. and Xu, L. and Ha, S. and Zimmermann, A. and Eggert, L. and Scheffenegger, R.},
|
||||
year = {2018},
|
||||
month = feb,
|
||||
pages = {RFC8312},
|
||||
institution = {{RFC Editor}},
|
||||
doi = {10.17487/RFC8312},
|
||||
language = {en},
|
||||
number = {RFC8312}
|
||||
}
|
||||
|
||||
@techreport{shelbyConstrainedApplicationProtocol2014,
|
||||
title = {The {{Constrained Application Protocol}} ({{CoAP}})},
|
||||
author = {Shelby, Z. and Hartke, K. and Bormann, C.},
|
||||
|
|
@ -315,7 +327,7 @@
|
|||
issn = {2151-1950, 2151-1969},
|
||||
doi = {10.4236/jgis.2014.65036},
|
||||
file = {/home/leopold/snap/zotero-snap/common/Zotero/storage/39HVB5X5/Spivak et al. - 2014 - Comparison of Digital Maps Recognition and Quanti.pdf},
|
||||
journal = {Journal of Geographic Information System},
|
||||
journal = {JGIS},
|
||||
number = {05}
|
||||
}
|
||||
|
||||
|
|
@ -363,7 +375,7 @@
|
|||
issn = {1949-2421, 1947-3826},
|
||||
doi = {10.4236/cn.2013.53B2056},
|
||||
file = {/home/leopold/snap/zotero-snap/common/Zotero/storage/SHNR6SNE/Zhao et al. - 2013 - Resource Allocation for OFDMA-MIMO Relay Systems w.pdf},
|
||||
journal = {Communications and Network},
|
||||
journal = {CN},
|
||||
number = {03}
|
||||
}
|
||||
|
||||
|
|
@ -376,7 +388,7 @@
|
|||
issn = {2329-3284, 2329-3292},
|
||||
doi = {10.4236/ojbm.2020.82046},
|
||||
file = {/home/leopold/snap/zotero-snap/common/Zotero/storage/KHZSTVS8/Zheng - 2020 - Research on Airport Taxi Resource Allocation Based.pdf},
|
||||
journal = {Open Journal of Business and Management},
|
||||
journal = {OJBM},
|
||||
number = {02}
|
||||
}
|
||||
|
||||
|
|
|
|||
247
rapport.tex
247
rapport.tex
|
|
@ -1,7 +1,7 @@
|
|||
% !TEX encoding = UTF-8 Unicode
|
||||
% -*- coding: UTF-8; -*-
|
||||
% vim: set fenc=utf-8
|
||||
\documentclass[a4paper,11pt,french]{article}
|
||||
\documentclass[a4paper,12pt,french]{article}
|
||||
|
||||
\usepackage{ensps}
|
||||
|
||||
|
|
@ -54,6 +54,14 @@
|
|||
|
||||
\newcommand{\coap}{\gls{coap}}
|
||||
|
||||
\newglossaryentry{cocoa}
|
||||
{
|
||||
name=Cocoa+,
|
||||
description={Evolution de \coap{}, protocol de la couche \osi{} 7}
|
||||
}
|
||||
|
||||
\newcommand{\cocoa}{\gls{cocoa}}
|
||||
|
||||
\newglossaryentry{keras}
|
||||
{
|
||||
name=keras,
|
||||
|
|
@ -102,6 +110,14 @@
|
|||
|
||||
\newcommand{\CC}{\gls{cc}}
|
||||
|
||||
\newglossaryentry{cca}
|
||||
{
|
||||
name=CCA,
|
||||
description={Algoritme de controle de congestion}
|
||||
}
|
||||
|
||||
\newcommand{\CCA}{\gls{cca}}
|
||||
|
||||
\newglossaryentry{mac}
|
||||
{
|
||||
name=MAC,
|
||||
|
|
@ -128,6 +144,8 @@
|
|||
|
||||
\newcommand{\qlearn}{Q-learning}
|
||||
\newcommand{\dqlearn}{Deep-Q-learning}
|
||||
\newcommand{\cubic}{TCP-Cubic}
|
||||
\newcommand{\newreno}{TCP-NewReno}
|
||||
|
||||
\newglossaryentry{rtt}
|
||||
{
|
||||
|
|
@ -298,6 +316,8 @@ L'interface en question est une interface \emph{RestFull} :\begin{itemize}
|
|||
\end{itemize}
|
||||
En plus de ses méthodes qui ont leurs equivalents chez \http{}, il y a la methode OBSERVE.
|
||||
Si un client demande à observé une ressource sur un serveur, le serveur lui enveré automatiquement la ressource à chaque fois que elle est modifiée.
|
||||
Les ressources utilisé avec \coap{} ne sont pas les même que en \http{}, on ne cherche pas à transféré une suite de centaine voir millier de paquet, mais un seul.
|
||||
Mais à la congestion classique se rajoute le risque de perte de paquet à cause des liaisons physique, car les infratructures sans fils sont soumise à de la perte aléatoire.
|
||||
|
||||
D'un point de vu technique, \coap{} a la particularité de reposé sur l'\udp{} et non le \tcp{}.
|
||||
Ainsi le \CC{} est réalisé par la couche applicative et non la couche transport.
|
||||
|
|
@ -308,6 +328,8 @@ Lorsque l'on envoie un message, il peut etre de deux type : \begin{itemize}
|
|||
\end{itemize}
|
||||
Les messages NCON ne sont donc pas réenvoyé si ils sont perdu à cause de la congestion, car il n'y a pas de moyen de la détecter.
|
||||
Cela peut ne pas etre un problème pour certaine application.
|
||||
Il y a aussi les messages de type ACK, qui aquite les message CON.
|
||||
L'association entre le message CON et ACK se fait grace à un token (ACK[0xe4] aquite le message CON[oxe4]).
|
||||
|
||||
Ses derniers temps, des nouvelles solutions bassé sur l'apprentissage machine se sont développé pour le \CC{} en \tcp{}.
|
||||
Notre problèmatique est donc de savoir si de tel solutions sont applicable à \coap{}.
|
||||
|
|
@ -330,7 +352,7 @@ La methode de base pour construire cette fonction est le \qlearn{}.
|
|||
C'est un possecus itératif où l'ont va construire un tableau (la Q-table), noté $\mathbb{Q} : \mathbb{S} \times \mathbb{A} \rightarrow \R$ associant à chaque couple observation/action une valeur.
|
||||
On parcours l'environement et à chaque pas de temps, on met à jour la valeur de $\mathbb{Q}(s_t, a_t)$ grace à la formule suivante : \begin{equation}
|
||||
\mathbb{Q}\left(s_t, a_t \right) := \left(1 - \alpha\right) \cdot \mathbb{Q}\left(s_t, a_t \right) + \alpha \cdot \left( r_t + \gamma \cdot max _ {a \in \mathbb{A}} \mathbb{Q} \left((s_{t+1}, a \right) \right)
|
||||
\label{qlearn_update}
|
||||
\label{eq:qlearn_update}
|
||||
\end{equation}
|
||||
Les deux paramètre sont : \begin{itemize}
|
||||
\item $\alpha$ le taux d'apprentissage, c'est à dire à quelle point les nouvelles informations écrasent les anciennes,
|
||||
|
|
@ -341,28 +363,239 @@ En réalité, on fait des actions aléatoire avec une probabilité faible pour e
|
|||
Deux des limites de cette solution sont la taille en mémoire d'un tel tableau quand les ensembles $mathbb{S}$ et $\mathbb{A}$ sont grands, et le temps qu'il faut pour que la convergence des valeur du tableau ais lieu.
|
||||
Pour palié à cela, on peut approximé la fonction par un réseau de neurrone, c'est le principe du \dqlearn{}.
|
||||
|
||||
\section{État de l'art}
|
||||
\section{État de l'art\label{part_cc}}
|
||||
Le \CC{} est un problème qui date du début des réseaux.
|
||||
La première version de \tcp{} date de 1983, mais de nouveau \CCA{} sont régulièrement publiés et mis en production.
|
||||
Comme ordre d'idée, le \CCA{} le plus utilisé de nos jour, \cubic{}, a été inclue dans Linux en 2006, dans MacOS en 2014 et dans Windows en 2017.
|
||||
Chaque \CCA{} a des avantage et inconvénient, et ne fait pas le même compromis entre delai et débit.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width = 0.8\textwidth]{png_img/comp_tcp_xiao.png}
|
||||
\caption[Comparaison des \CCA{} en \tcp{}]{Comparaison de différents \CCA{} en \tcp{}. Figure issu de \cite{xiaoTCPDrincSmartCongestion2019}.}
|
||||
\label{fig:comp_cca_tcp}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Comment gère-t-on la congestion en \tcp{} ?}
|
||||
|
||||
\subsection{Influences de l'apprentissage machine dans le contrôle de congestion ?}
|
||||
Le \tcp{} suppose que il y a un grand nombre de paquet à transmettre.
|
||||
Ainsi on décide d'une fenetre de congestion, c'est à dire le nombre de paquet en attente d'aquitement.
|
||||
Si un paquet n'est pas aquité avant la fin d'un \rto{} fixe, on le réenvoie.
|
||||
Les \CCA{} on pour rôle de gérer la taille de la fenetre, et le \rto{} pour optimisé la connexion.
|
||||
|
||||
\subsection{Comment gère-t-on la congestion avec l’implémentation classique de \coap ?}
|
||||
Les \CCA{} de \tcp{} sont nombreux (une classification partiel est lsible dans \cite{haileEndtoendCongestionControl2021}), je ne vais donc pas tous les décrire.
|
||||
Le principe de base de la plupart des algoritmes est l'AIMD (additive-increase-multiplicative-decrease).
|
||||
Par exemple \newreno{}, le prédececeure de \cubic{}, augmente la taille de la fenetre par pas de $1$ tout les \rtt{}, et multiplie la taille par $\frac{1}{2}$ en cas de détéction de congestion.
|
||||
L'évolution proposé par \cubic{} est de ne pas venir croitre linéairement, mais de suivre une courbe cubique pour revenir en douceur à la taille de fenetre qui avait causé la congestion.
|
||||
Dans les deux cas, à chaque retransmission d'un message, le \rto qui lui est accordé double.
|
||||
|
||||
D'autre \CCA{} utilise les variations du \rtt{} pour estimer l'état de congestion du réseau.
|
||||
Le \rtt{} est le temps qui sépparre l'émittion d'un paquet de la reception de l'aquitement.
|
||||
Le \rtt{} est composé de deux parties : \begin{itemize}
|
||||
\item le temps de propagation, qui correspont au temps que met le signal à faire le trajet, il est incompressible (sauf changement de route),
|
||||
\item le temps d'attente dans les queues, qui est le temps passé dans les queues des différents routeurs et qui dépend dirrectement de la congestion du réseau.
|
||||
\end{itemize}
|
||||
Ainsi l'augmentation du \rtt{} est souvent signe que le réseau se congestionne.
|
||||
Mais interpréter ces varriation de \rtt{} et prendre la décision adécoite est trop complexe pour un algoritme classique, et certain on déjà proposé des solutions utilisant de l'IA \cite{xiaoTCPDrincSmartCongestion2019,liQTCPAdaptiveCongestion2019} .
|
||||
|
||||
\subsection{Comment gère-t-on la congestion avec l’implémentation classique de \coap{} ?}
|
||||
|
||||
Pour le \coap{}, la gestion de la congestion est différente, car on utilise une fenetre unitaire, c'est sur le \rto que se fait le travail.
|
||||
Dans la version de base, le \rto{} de base est tiré aléatoirement entre $2 s$ et $3 s$, et est doublé à chaque retransmission.
|
||||
C'est un protocole simple mais peu performant, car si le delai de transition est déjà de l'ordre du \rto, alors il risque d'avoir des retransmission systèmatique.
|
||||
|
||||
Une des évolution du \coap{} est \cocoa{}, qui ne change que le \CCA{}\cite{ancillottiRTTBasedCongestionControl2018}.
|
||||
C'est une algorithme inspiré de FAST-\tcp{} et Compound-\tcp{}.
|
||||
Ici on met en place une estimation du \rtt{} à partir de la mesures du \rtt{} de chaque message.
|
||||
A chaque reception d'un nouveau \rtt{} $r$, on met à jour l'estimation grace aux formules suivantes :
|
||||
\begin{equation}
|
||||
\begin{aligned}
|
||||
RTT_S &:= \alpha_S r + \left( 1 - \alpha_S \right) \cdot RTT_S\\
|
||||
RTT_L &:= \alpha_L r + \left( 1 - \alpha_L \right) \cdot RTT_S\\
|
||||
RTTVAR_L &:= \beta_L \left\| RTT_L - r \right\| + \left( 1 - \beta_L \right) \cdot RTTVAR_L
|
||||
\end{aligned}
|
||||
\label{eq:cocoa:estimateur}
|
||||
\end{equation}
|
||||
Ensuite, on crée une fonction $T$ permetant de prendre une decision :
|
||||
\begin{equation}
|
||||
T\left( \gamma \right) = RTT_L + \gamma RTTVAR_L
|
||||
\label{eq:cocoa:decision}
|
||||
\end{equation}
|
||||
On a donc $4$ cas pour prendre un décision : \begin{itemize}
|
||||
\item $RTT_S < T\left( -1 \right)$ : pas de congestion, on peut etre beaucoup plus agressif,
|
||||
\item $T\left( -1 \right) \le RTT_S < T\left( +1 \right)$ : congestion faible, on se trouve à un point de fonctionement correct, on ne change rien, mais on peut aussi etre un peu plus agressif si besoin,
|
||||
\item $T\left( +1 \right) \le RTT_S < T\left( +2 \right)$ : congestion normal, la congestion augmente, il faut etre moins agressif pour ne pas congestioner le réseau,
|
||||
\item $T\left( +2 \right) \le RTT_S$ : congestion importante, le réseau est totalement congestioner, il faut etre beaucoup moins agressif.
|
||||
\end{itemize}
|
||||
La seule contrainte est que $\alpha_S \gg \alpha_L$.
|
||||
Le choix des autres valeurs, les seuils est les actions prisent sont choisit empiriquement, on ne sais pas si elles sont optimale.
|
||||
|
||||
\subsection{Comment l'apprentissage machine prend place dans les \CCA{}?}
|
||||
Pour palier à ces problèmes, plusieurs \CCA{} utilisant de l'apprentissage machines sont apparut : Q-\tcp{}\cite{liQTCPAdaptiveCongestion2019}, \tcp{}-Drinc\cite{xiaoTCPDrincSmartCongestion2019}\dots
|
||||
L'idée derriere ses algorithme est de délégé la prise de decision à une IA qui serais capable de reconnaitre les signe de la congestion bien plus efficassement que une algorithme "fait-main" classique.
|
||||
Plusieurs problèmatique se présentent : \begin{itemize}
|
||||
\item La modélisation de l'environement : \begin{itemize}
|
||||
\item quel est $\mathbb{S}$, c'est à dire comment représenter l'environement pour l'acteur,
|
||||
\item quel est $\mathbb{A}$, c'est à dire qu'es ce que l'acteur doit donner comme consigne,
|
||||
\item quel est $r_t$, c'est à dire qu'es ce qu'une bonne action
|
||||
\end{itemize}
|
||||
\item mais aussi des problèmes de compétition multi-agents: \begin{itemize}
|
||||
\item comment etre sûr que les ressource réseau sont équitablement répartie entre les agents,
|
||||
\item comment etre sûur que les agent IA ne vont pas perturber les agents non-IA,
|
||||
\end{itemize}
|
||||
\item ainsi que des problèmes d'implémentation, car tout cela toi tourner sur une machine très peu puissante et incapable de faire des calcul complexe.
|
||||
\end{itemize}
|
||||
Les intégration de l'IA dans le \CC{} n'est encore qu'a l'état de test, de balbutiment, et pourtant des résultats notables et encouragant sont déjà disponible, voir figure \ref{fig:comp_cca_tcp}, ce qui nous motive à tenter de développer des solutions similaire pour \coap{}.
|
||||
|
||||
\section{Modélisation choisit}
|
||||
La première étape est de modélisé le système.
|
||||
Pour la modélisation, je m'appuis sur la modélisation de \cite{xiaoTCPDrincSmartCongestion2019}.
|
||||
|
||||
\subsection{Quels cas d'utilisations nous est le plus favorable ?}
|
||||
Pour notre travail, on se positionne dans une situation où un serveur centrale puissant voudrait récupérer des données sur un ensemble de capteur.
|
||||
Les contraites pour les codes s'éxécutant sur le serveur centrale (un serveur cloud généralement) et sur les capteur sont radicalement différentes.
|
||||
Le cloud peut exécuter le code qu'il veux avec beaucoup de puissance, alors que les capteur doivent se limité au maximum.
|
||||
Le could à acces au données de toutes les connexion, alors que les capteurs n'ont à priori que les données de leur connexion.
|
||||
On choisit de se placer dans le cas où on intéragie avec un nombre fixe de capteur, $N$.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{puml/cas_utilisation_coap.png}
|
||||
\caption[Diagramme de séquance de transaction \coap{}, cas 1]{Diagramme de séquance entre le capteur et le serveur \coap{} avec déclanchement de la transaction par le capteur.}
|
||||
\label{fig:seq_coap:1}
|
||||
\end{figure}
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{puml/cas_utilisation_coap_001.png}
|
||||
\caption[Diagramme de séquance de transaction \coap{}, cas 2]{Diagramme de séquance entre le capteur et le serveur \coap{} avec déclanchement de la transaction par le cloud, et réponse dans l'aquitement.}
|
||||
\label{fig:seq_coap:2}
|
||||
\end{figure}
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{puml/cas_utilisation_coap_002.png}
|
||||
\caption[Diagramme de séquance de transaction \coap{}, cas 3]{Diagramme de séquance entre le capteur et le serveur \coap{} avec déclanchement de la transaction par le could, et réponse dans un message sépparré.}
|
||||
\label{fig:seq_coap:3}
|
||||
\end{figure}
|
||||
|
||||
Lorsque on veux établir une connexion avec un capteur, il y a trois cas de figure, il nous faut donc choisir celui qui nous avantage le plus. Le cas 1 (figure \ref{fig:seq_coap:1}) permet de réagir à un evenement, mais ne demande au capteur de prendre le rôle de gestionaire du \CC{}, ce qui n'est pas le plus simple.
|
||||
Le cas 2 (figure \ref{fig:seq_coap:2}) et 3 (figure \ref{fig:seq_coap:3}) permet tout deux au cloud de prendre en charge le \CC{}, mais le cas 3 demande l'échange de bien plus message, il sature plus vite le réseau.
|
||||
On choisit dans de travailler dans le cas 2, qui permet d'avoir à la fois toutes les informations au niveau de l'acteur, et de la puissance de calcul.
|
||||
Pour ce qui est de la gestion des evenement, on peu imaginé que le could envoie régulièrement au capteur des consigne siple pour le \CC{}, même si nous n'allons pas taiter cette problèmatique.
|
||||
|
||||
\subsection{Quelle sont les variables que nous pouvons observer ?}
|
||||
|
||||
La grandeur la plus simple à se représenter est le \rtt{}.
|
||||
Chaque envoie de message permet de récupérer un echantillion de \rtt{}.
|
||||
Mais un problème se pose lorsque le \rto{} de base est plus faible que le \rtt{} à cause des retransmissions : on ne sais pas si l'aquitement vient de l'original ou de la rentransmition, car ils ont le même token.
|
||||
Par exemple, dans la figure \ref{fig:temp_coap:valide}, on à sans ambiguité un \rto{} de $25$, mais dans la figure \ref{fig:temp_coap:invalide}, le \rto{} semble etre $5$ alors que il est de $30$.
|
||||
Ce problème peut etre contourné en changeant le token dans les retransmissions, mais nous ne metterons pas en place cette solution pour l'instant.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[scale = 0.7]{puml/temporal_transaction_valide.png}
|
||||
\caption{Diagramme temporelle d'un transaction sans ambiguité du \rtt{}.}
|
||||
\label{fig:temp_coap:valide}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[scale = 0.7]{puml/temporal_transaction_invalide.png}
|
||||
\caption{Diagramme temporelle d'un transaction avec ambiguité du \rtt{}.}
|
||||
\label{fig:temp_coap:invalide}
|
||||
\end{figure}
|
||||
|
||||
L'autre grandeur que l'ont peur facilement mesuré est le nombre de retransmission de chaque message.
|
||||
C'est retransmission peuvent etre dû à la congestion, mais aussi à des erreures de routage ou des couches réseau physique.
|
||||
|
||||
\subsection{Comment représenter un état du système ?}
|
||||
\cite{jainQuantitativeMeasureFairness1998}
|
||||
|
||||
Une fois que l'on a mesurer une grandeur, il faut la transmetre à l'acteur.
|
||||
Le premier problème est que l'acteur vois un temps discontinu, alors que les nouvelles mesures arrive à des instants irréguliers.
|
||||
On choisit donc de couper le temps en une série d'interval de longueur fixe.
|
||||
Dans ces intervals, on supose que l'état du réseau est constant, et les valeur utilisé par le \coap{} le sont aussi.
|
||||
Il faut prendre une durée de l'interval qui soit plus longue que le \rtt{}, car ainsi on ne se retrouve pas dans un cas limite où un message part pendant l'intervale $t$, avec les consignes de l'instant $t$, mais arrive dans l'instant $t+1$ et influe $s_{t+1}$ ou lieu de $s_t$.
|
||||
Mais il faut aussi que cette durée ne soit pas trop importante, car on ne change les consignes que à la fin de ces intervales.
|
||||
On nomme cet interval "interval de controle".
|
||||
|
||||
De plus, on travail sur un réseau de capteur qui renvoie leurs informations à un serveur cloud unique.
|
||||
Puisque le serveur cloud centralise toutes les connexions, on choisit d'avoir un seul agent, qui donne des consignes pour toutes les connexions.
|
||||
|
||||
Pour la suite, on appel "serveur \coap{}" la partie de programme s'executant sur les capteurs, et "clients \coap{}" les programmes s'éxecutant sur le serveur cloud afin de récupérer les données des capteurs.
|
||||
On remarque aussi que on ne fait pas la différence entre l'état du réseau et l'observation que l'on en fait.
|
||||
|
||||
\subsubsection{État d'un client seul.}
|
||||
Pour commencer, il faut que chaque client \coap{} soit capable de représenter sa connexion.
|
||||
Pour cela, on dispose de : \begin{itemize}
|
||||
\item le nombre de messages envoyer penant l'interval de control,
|
||||
\item et pour chaque message : \begin{itemize}
|
||||
\item le nombre de retransmission,
|
||||
\item le \rtt{} mesurer.
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
On construit ensuite les valeurs suivantes : \begin{itemize}
|
||||
\item $RTT_{min}$, le minimum du \rtt{} pendant les $n_m$ derniers interval de control,
|
||||
\item $\overline{RTT}$, la moyenne du \rtt{} sur l'interval de control,
|
||||
\item $\eta = \frac{RTT_{min}}{\overline{RTT}}$
|
||||
\item $\nu = \frac{n_{retransmission}}{n_{message}}$
|
||||
\item $VARRTT = \frac{RTT_S}{RTT_L}$ à partir des deux valeurs suivantes, que on met à jour à chaque nouvel mesure du \rtt{} $r$ :\begin{align*}
|
||||
RTT_S &:= \alpha_S \cdot r + \left( 1 - \alpha_S \right) \cdot RTT_S \\
|
||||
RTT_L &:= \alpha_L \cdot r + \left( 1 - \alpha_L \right) \cdot RTT_L \\
|
||||
\alpha_S &\gg \alpha_L
|
||||
\end{align*}
|
||||
\end{itemize}
|
||||
|
||||
Ces valeurs sont plus représentative que les mesures brutes.
|
||||
$RTT_{min}$ permet d'estimé le temps de propagation des messages (on rappel que $RTT = \tau_{propagation} + \tau_{queue}$).
|
||||
Ainsi, $\eta$ permet d'estimer le pourcentage du temps passer dans les queues par les messages au cours de leur voyage.
|
||||
Lorsque $\eta$ est proche de $1$, c'est que les queues sont presque vide, et losque il est proche de $0$, c'est qu'elle represente la majorité de temps de trajet, ce qui est signe de congestion.
|
||||
$\nu$ represente le taux de redondane des messages, il doit etre le plus faible possible.
|
||||
$\nu$ élevé signifi que on revoie des messages et donc que les consignes ne sont pas adapté.
|
||||
Mais $\nu$ est aussi influancé par les défauts du réseau, donc ce n'est pas un indicateur parfait.
|
||||
$VARRTT$ permet d'estimer l'évolution du \rtt{} en comparant deux filtrages des \rtt{} sur des echelles différentes.
|
||||
$VARRTT > 1$ indique que la tendance est à la hausse des \rtt{}, et donc que la longueur des queues augmente, et $VARRTT < 1$ que la tendance est à la baisse.
|
||||
Il faut tout de même que le filtrage $RTT_S$ se fasse sûr plusieurs echantillions du \rtt{} (donc $\alpha_S \sim 0.1$) car la mesure du \rtt{} est très bruité.
|
||||
|
||||
Une fois ces valeur calculer, on construit le vecteur suivant, qui represente l'état du client $i$ : \begin{equation}
|
||||
s ^ {\left( i \right)}= \begin{bmatrix} \nu\\ \eta \\ VARRTT \end{bmatrix}
|
||||
\label{eq:modele:vec}
|
||||
\end{equation}
|
||||
|
||||
\subsubsection{État de l'ensemble des clients.}
|
||||
Une fois que chaque client a generé sont vecteur, il suffit de les concaténés pour crée une matrice où chaque ligne représente une des trois valeurs, et chaque colonne un client.
|
||||
\begin{equation}
|
||||
S = \begin{bmatrix} s ^ {(0)} & \cdots & s^{(N)} \end{bmatrix}
|
||||
\label{eq:modele:mat}
|
||||
\end{equation}
|
||||
L'avantage d'une tel matrice est que on pourra utiliser une convolution dans le réseau de nerrone.
|
||||
Une autre possibilité, que je n'ais pas pu tester est de concaténer les matrices de plusieur echantillion de temps successif pour crée un tenseur à trois dimension, qui permetrait d'avoir plus d'informations sur l'évolution temporelle des valeurs.
|
||||
|
||||
\subsection{Comment l'acteur influance le client \coap{} ?}
|
||||
La principales valeur permetant de controler le comportement du client est le \rto{}.
|
||||
On choisit une solution où $\mathbb{A} = \R ^ N$.
|
||||
Si on note $c_t$ le vecteur des $N$ \rto{} à l'instant $t$, et $a_t$ le vecteur d'action généré par l'acteur, alors :
|
||||
\begin{equation}
|
||||
c_{t+1} ^ {\left( i \right) }= c_t ^{\left( i \right)}\cdot \begin{cases}
|
||||
1 + a _ t ^ {\left( i \right)} & \text{si } a _ t ^{\left( i \right)} \ge 0 \\
|
||||
\frac{1}{1 - a _ t ^ {\left( i \right)}} & \text{si } a _ t ^{\left( i \right)} < 0
|
||||
\end{cases}
|
||||
\end{equation}
|
||||
L'effet de cette action est visible dans la figure \ref{fig:modele:action}.
|
||||
Cette action permet d'avoir la capacité de réagir rapidement avec des grandes actions, mais aussi d'avoir de la précision pour s'ajuster autour du point de fonctionement.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width = 0.7\textwidth]{png_img/gain_action.png}
|
||||
\caption[Modification du \rto{} par l'action.]{Modification du \rto{} par l'action, pour un seul client, en échelle logaritmique.}
|
||||
\label{fig:modele:action}
|
||||
\end{figure}
|
||||
|
||||
D'autre choix sont possibles, par exemple $\mathbb{A} = \left\lbrace 0.1, 0.5, 0.8, 1, 1.25, 2, 10 \right\rbrace ^ N$, et $c ^ {\left( i \right))} _{t+1} c_t ^ {\left( i \right))} \cdot a _ t ^ {\left( i \right))} $
|
||||
|
||||
\subsection{Comment quantifier la réussite de l'agent ?}
|
||||
Une fois que l'on sais représenter l'état du réseau, il faut déterminer si cette état est favorable ou non.
|
||||
Pour cela, il faut se demander ce que l'on veux comme caractéristique
|
||||
|
||||
\subsection{Quel type d'agent utilisé ?}
|
||||
|
||||
\subsection{Comment récolté de l'expérience ?}
|
||||
|
||||
|
|
@ -392,7 +625,7 @@ Pour palié à cela, on peut approximé la fonction par un réseau de neurrone,
|
|||
|
||||
\subsection{Multiplication des clients}
|
||||
|
||||
\subsection{Multiplication des \rasp}
|
||||
\subsection{Multiplication des \rasp{}}
|
||||
|
||||
\clearpage
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue