diff --git a/src/content/birbnetes_impl.tex b/src/content/birbnetes_impl.tex
index 108b634..4b6a775 100644
--- a/src/content/birbnetes_impl.tex
+++ b/src/content/birbnetes_impl.tex
@@ -92,6 +92,7 @@ Emellett természetesen a jelenlegi \acrshort{iot} szoftverben is módosítást
 \subsection{Implementáció}
 
 \subsubsection{Előszűrő szolgáltatás}
+\label{sec:prefilter_service_implementation}
 
 A mikroszolgáltatás fejlesztését \gls{python} nyelven végeztem. Azért ezt választottam, mert az \acrshort{iot} eszközön futó szoftver korábban abban íródott, ezért a releváns komponenseket könnyen át tudtam emelni.
 
diff --git a/src/content/scheduling.tex b/src/content/scheduling.tex
index 620d512..aadbf60 100644
--- a/src/content/scheduling.tex
+++ b/src/content/scheduling.tex
@@ -64,12 +64,25 @@ A következőkben a korábban bemutatott alkalmazásokat fogom megvizsgálni abb
 
 Ebben az alkalmazásban a peremhálózati adatközpontba egy előszűrést megvalósító komponens kerül. Ennek a komponensnek a feladata, hogy a sok \acrshort{iot} eszköz által feltöltött hangminták által generált hálózati terhelést csökkentse azzal, hogy intelligens felismerést futtatva csak a releváns hangmintákat küldi tovább.
 
-Ez a komponens állapotmentes és 
+Ez a komponens állapotmentes, két kérés teljesítésének eredménye egymástól teljesen független. Ennek köszönhetően könnyen skálázható több példányra, hogy képes legyen nagy mennyiségű klienst kiszolgálni. Mivel a peremhálózati adatközpontokban -- a felhőhöz képest -- általában korlátozottan állnak csak rendelkezésünkre erőforrások, ezért nem tudjuk tetszőlegesen skálázni a feldolgozó szolgáltatásunkat. 
+
+Előfordulhat olyan helyzet, amikor a peremhálózat kifogy a számítási kapacitásból. Ilyen esetben is szeretnénk legalább annyi terhelést megtartani a használt peremhálózati adatközpontban, amennyit az teljesíteni képes a fennmaradó terhelést pedig szeretnénk átütemezni egy másik peremhálózati adatközpontba vagy végszükségben a felhőbe. Ezzel annyi sávszélesség kihasználtságot spórolni, amennyire csak képesek vagyunk.
 
 \subsubsection{Ütemezési döntés meghozása}
 
+Ebben az alkalmazásban azt szeretnénk megvalósítani, hogy ha egy adatközpontban fogytán van a számítási kapacitás, akkor más adatközpontokhoz tudjunk fordulni a feladataink végrehajtásával. Ebből következik, hogy szükségünk van arra, hogy mérjük egy adatközpont terheltségét. 
+
+A futó előszűrő szoftver komponens teljesítőképességéről egy jó jellemző a várakozási sorának hossza. \Aref{sec:prefilter_service_implementation}.\ szekcióban ismertetettek szerint a szolgáltatás fenntart egy várakozási sort, ahol a feldolgozásra váró adatokat állítja sorba. Ideális esetben, ha miden beérkező kérést időben el tud látni, akkor ennek a sornak a hossza stabil 1 körüli érték. Ha a szolgáltatás teljesítőképessége végéhez közeledik, akkor elkezdenek felgyűlni a feladatai, ezáltal a sorhossz monoton növekedésnek indul.
+
+Szükség van támogatásra az előszűrő szolgáltatástól, hogy gyűjteni tudjuk a futó szolgáltatások belső sorhosszát.
+
 \subsubsection{Ütemezés megvalósítása}
 
+Mivel az előszűrő szolgáltatás állapotmentes működést valósít meg, ezért könnyedén lehet mozgatni az egyes adatközpontok között, illetve több példányban is futtatni egyszerre.
+
+Az \acrshort{iot} eszközök egy előre beállított címre küldik a hangmintákat. Ez a cím az egyes adatközpontoknál más és más lehet. Mivel a szolgáltatásokat adatközpontok között mozgatjuk, ezért szükség van támogatásra a az eszközök részéről is, hogy dinamikusan meg tudjuk változtatni a küldés célját.
+
+
 \subsection{Robot vezérlés}
 
 A felhő alapú robotkarok alkalmazásánál a peremhálózati adatközpontba egy vagy több alacsony szintű mozgást vezérlő komponens kerülhet. Ezek egymással egy osztott memóriát megvalósító \textit{Redis} adatbázison keresztül kommunikálnak. Ezek a komponensek belső állapottal rendelkeznek. Létrehozásukkor megkezdik a hozzájuk rendelt \textit{program} letöltését és futtatását. Ha a \textit{program} véget ért, akkor a komponensek kilépnek.
@@ -93,10 +106,15 @@ A vezérlést megvalósító szolgáltatás komponensek indításáért ebben az
 
 \section{Ütemező rendszer}
 
+Bár a két alkalmazás működése és igényei jelentősen eltérnek, szerettem volna egy olyan rendszert megalkotni, aminek segítségével mindkét alkalmazás ütemezése megoldható.
+
+\subsection{Metrikák gyűjtése és felhasználása}
+
+% bele van tolva influx db-be
+% Az infulxdbj nagyon jó mert tud egy csomó midnent például deriválni
 
 \subsection{Algoritmus}
 
-Egy ilyen algoritmusnak fel kell tudnia mérni, hogy melyik a legideálisabb környezet futtatni a szolgáltatást. Sajnos az, hogy mi számít ideális környezetnek, az erősen alkalmazás függő. Vannak alkalmazások, amelyeknél a késleltetés minimalizálása a kliensek felé a cél, de olyan is van, ahol pont a hálózati forgalom aggregálása a cél. Ezért a megfelelő algoritmus megalkotásához szükség van támogatásra a konkrét alkalmazástól.
 
 %Egy ilyen algoritmusnak fel kell tudnia mérni azokat