Monday, December 17, 2018

PTE Academic Preparation - Key Notes

Task: Writing 20 mins

High-Level Structure

1-Introduction

Rewrite general sentence
Briefly, mention side 1 &2
Your opinion

2-Side 1

3-Side 2

4-Conclusion

Task: Writing 10 mins

Read-2 mins
Write-7 mins
Edit-1 min

Who did.. what??
Don't write the paragraph, passage etc..

Task: Speaking

Read: 25 Sec
Speak:40 Sec

Introductory Sentences-5 Sec ( This bar/line/pie graph--- represents + Title + X-axis)
Image Description-25 Sec
Conclusion-5 Sec (Overall, Main trends)

Task: Reading

Rearranging Paragraph: Find independent Sentence








Wednesday, November 7, 2018

How to get Hired on your dream Position

Applicant tracking system

From Wikipedia, the free encyclopedia
Jump to navigationJump to search
An applicant tracking system (ATS) is a software application that enables the electronic handling of recruitment needs. An ATS can be implemented or accessed online on an enterprise or small business level, depending on the needs of the company and there is also free and open source ATS software available. An ATS is very similar to customer relationship management (CRM) systems, [1] but are designed for recruitment tracking purposes. In many cases they filter applications automatically based on given criteria such as keywords, skills, former employers, years of experience and schools attended.[2] This has caused many to adapt resume optimizationtechniques similar to those used in search engine optimization when creating and formatting their résumé.[3]

Saturday, October 6, 2018

Certified Kubernetes Administrator (CKA) Program

The Certified Kubernetes Administrator (CKA) program was created by the Cloud Native Computing Foundation (CNCF), in collaboration with The Linux Foundation, to help develop the Kubernetes ecosystem. As one of the highest velocity open source projects, Kubernetes use is exploding.

The Cloud Native Computing Foundation is committed to growing the community of Kubernetes Administrators, thereby allowing continued growth across the broad set of companies and organizations that are using Kubernetes. Certification is a key step in that process, allowing certified administrators to quickly establish their credibility and value in the job market, and also allowing companies to more quickly hire high-quality teams to support their growth.


About the Program

The Cloud Native Computing Foundation offers a certification program that allows users to demonstrate their competence in a hands-on, command-line environment. The purpose of the Certified Kubernetes Administrator (CKA) program is to provide assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.
It is an online, proctored, performance-based test that requires solving multiple issues from a command line.
The CKA program is separate from Kubernetes Certified Service Provider (KCSP) program. You can become a CKA without needing to be involved with a KCSP, but for a company to become a KCSP it must employ at least three CKAs. You can learn more about the KCSP program.
CNCF has open sourced the curriculum around which the CKA exam has been created for the benefit of companies offering training. CNCF offers wholesale pricing on our exams to training companies purchasing in bulk. For more information, please contact trainingpartners@cncf.io.

Exam Details

The online exam consists of a set of performance-based items (problems) to be solved in a command line running Version 1.11.1 and candidates have 3 hours to complete the tasks.
The Certification focuses on the skills required to be a successful Kubernetes Administrator in industry today. This includes these general domains and their weights on the exam:
  • Application Lifecycle Management 8%
  • Installation, Configuration & Validation 12%
  • Core Concepts 19%
  • Networking 11%
  • Scheduling 5%
  • Security 12%
  • Cluster Maintenance 11%
  • Logging / Monitoring 5%
  • Storage 7%
  • Troubleshooting 10%
The cost is $300 and includes one free retake. For questions on the exam, please reach out to certificationsupport@cncf.io.
Quarterly exam updates are planned to match Kubernetes releases.

Sunday, September 30, 2018

eSIM cards

Figure 3 Remote SIM Provisioning System (GSMA RSP Technical Specification – SGP.22)
The SM-DP+ (Subscription Manager Data Preparation - enhanced compared to the SM-DP in SGP.02) is responsible for the creation, generation, management and the protection of resulting profiles at the input/request of the operator.
The LPA (Local Profile Assistant) is a software running in the device and provides LPA services, such as Profile download or Profile management, to the eUICC. The LPA consists of two parts - the LPD (Local Profile Download) and the LUI (Local User Interface). The LPD plays a proxy role for the efficient download of a Bound Profile Package between SM-DP+ and eUICC, while the LUI allows for local profile management on the device by the end user.
The Certification Issuer (CI) issues Certificates for remote SIM provisioning entities and acts as a trusted third party for the purpose of authenticating the entities within the system.
The eUICC Manufacturer (EUM) is responsible for the initial cryptographic configuration and security architecture of the eUICC and is the provider of eUICC products.

The Operator (Mobile Network Operator or Mobile Virtual Network Operator) provides access and communication services to its subscribers through their mobile network infrastructure.


Monday, September 24, 2018

PTE(The Pearson Test of English Academic)

Why?
The Pearson Test of English Academic (PTE Academic) is the English test trusted by universities, colleges and governments around the world.

Saturday, August 25, 2018

NB-IoT

Throughout parts one and two I discussed the concepts of IoT and (I)IoT, (big) data analytics, data placement, the triggering of workflows and I had a more detailed look at the LPWAN and LTE (cellular) type networks. I also included a cheat sheet where I highlighted 6 of the most common (and upcoming) (I)IoT networks including their main characteristics and features. Today I’d like to focus on the various individual networks mentioned like: Sigfox, LoRa, NB-IOT etc. and talk a bit more about their background and future potential.
Since all the network types covered below are part of the earlier published IoT networking technology cheat sheet, I’ve included it in this post as well.
Sigfox
In 2009 Sigfox started to build the first modern LPWAN network (France), which quickly took off, especially within Europe, and it continues to grow by the day. I recently spoke to some of the Dutch Sigfox representatives and their story was quite impressive, as were their numbers.
And while today’s LPWAN networks have a lot in common with their pressers, one of the biggest differences is today’s online integration making it possible to apply (near) real-time monitoring, and all the benefits that come with it – also the main reason why these types of networks have become so popular in such a short time frame, which goes for some of the other networks as well.
Sigfox is best used for (extreme) low bandwidth applications, especially where energy consumption, or the lack of it, plays a critical role. As mentioned in the cheat sheet as well, it is an open (proprietary) standard, which has its pros and cons. Like LoRa, it is a completely separate network exclusively designed just for IoT purposes. It operates at 868 GHz in Europe and at 900 MHz throughout the USA.
Europe (including the UK) has by far the broadest coverage to date, and as mentioned is still expanding on a daily basis. In the USA Sigfox is still heavily under construction as you can clearly see on their website as well. Parts of Chicago, Miami, San Diego and San Francisco do already have solid coverage – more to come, I’m sure. As far as some of the more technical details go, have a look at the earlier mentioned cheat sheet below or here.
LoRa
Stands for Long Range and is one of the better known LPWAN’s, or Low Power Wide Area Networks. Data throughput rates range from 0.3 tot 50 Kbit/s as described in the LoRa(Wan) R1.0 Open Standard for the IoT, which broadens its range for several other use-cases besides low power, low battery consumption as compared to Sigfox, for example. When it comes to low power consumption, LoRa uses something called an Adaptive Data Rate algorithm, or ADR to optimize and control battery life and network capacity. In short: the LoRaWAN network server manages the data rate for each connected sensor via an algorithm. A unique approach.
When there’s is talk of LoRa, LoRaWAN is almost always mentioned in the same sentence and does tend to cause some confusion from time to time. LoRa is a technology developed by the chip manufacturer, Semtech, which is also why it’s not considered an open standard, but proprietary like Sigfox. LoRa refers to wireless modulation allowing low power communication – think of it as the physical layer. LoRaWAN, on the other hand, refers to the networking protocol making use of the above-mentioned LoRa (Semtech) physical components enabling medium to long-range, low power communication – I hope that makes sense.
Back in June 2016 The Netherlands became the first country to have a nationwide LoRa network for IoT purposes, rolled out by KPN, by the way. Nationwide coverage (or close to) of LoRa can also be found in Belgium, France and big parts of Italy, with Germany soon to follow as well. Other parts of the world where LoRa is being deployed include but are not limited to: the USA, New Zeeland, Australia, Japan, India (Tata steel communications) and more. One advantage that LoRa (Again, the physical part) has over other LPWAN offerings, is the option to also deploy private networks, which is also one of the main reasons it is so widely spread.
NB-IOT
NB-IOT is another 3GPP Rel. 13 proposal, like LTE Cat 0 and 1, though it doesn’t operate in the LTE band/spectrum. The technology used is DSSS modulation, as highlighted in the cheat sheet as well. It’s still fairly new, in fact the requirements of the 3GPP Rel. 13 standard for NB-IOT have just been finalized as of early 2016. Note that there is also a cellular LTE based LPWAN option named LTE-M, based on the 3GPP standard, which will be discussed later.
While NB-IOT can’t operate in the LTE spectrum directly, it can make use of existing LTE base stations/networks. Resource blocks can be allocated for NB-IOT purposes, either ‘in-band’ or in the so-called LTE ‘guard-bands’. The question is: will current LTE carriers do/allow this since reducing the number of current LTE ‘blocks’ automatically means less capacity, and thus income on the LTE side. It will come down to, which one will be most profitable and future-proof, though this can be a tough question to answer.
For all this to work (the reuse of LTE resource blocks) different software and a couple of additional modifications will be needed, and in the case of Alcatel based infrastructures new hardware will need to be installed as well, meaning an upfront investment, which could turn out to be costly for the carriers involved. As a second option, unused 200 kHz bands that have been previously used for GSM networks could also be leveraged/reused for NB-IOT purposes. So, depending on which type of network (GSM or LTE) has a bigger presence in a certain area, country or continent even, one will probably have a preference over the other.
Within an NB-IOT network all data is directly sent to the main server (s), so no gateways are needed, unlike most of the other (narrowband) IoT networks out there. No gateways, means less infrastructural components, equals less (er) upfront investments. Next to that, ‘NB-IOT only’ chips, when compared to LTE will be simpler and cheaper to manufacture – the all-over component costs are lower.
Even though there are still a lot of uncertainties, pros and cons to the various network types available today – and still in development, quite a few (big) companies are interested and investing in NB-IOT type networks, like: Huawei, Ericsson, Qualcomm, and Vodafone.
LTE-M
Next to NB-IOT (as previously discussed) the 3rd Generation Partnership Project (3GPP) also introduced LTE-M, which is short for LTE-MTC (Machine-Type Communication), also known and referred to as Cat-M. Another narrowband, low (er) power network option that can co-exist with other LTE services. Together with NB-IOT they expand the LTE technology portfolio to support an even wider range of low-power IoT use cases. An LTE-M network should also be able to offer up to 10 years of battery life on a 5WH battery.
One of the main advantages of LTE-M over NB-IOT is that it is compatible with existing LTE networks. The only thing LTE carriers will have to take care of is a relatively simple software upgrade, at least on paper. Besides that, LTE-M is also seen as more secure and can handle higher data rates as well. Because existing LTE/4G networks are used and the maximum data rate of an average LTE device is ‘only’ around 100 Kbits/s the network won’t be heavily utilized. Also, carriers can offer pricing closer to 2G service plans instead of 4G. As a result, LTE-M is often seen as being superior to NB-IOT.
Both LTE-M and NB-IOT are part of the 3GPP Release 13. Release 14 is supposed to bring new capabilities such as single-cell multicast to both eMTC and NB-IoT, enabling easy over-the-air firmware upgrades as well as enhanced device positioning for asset location tracking.
LTE-M and NB-IOT are both being rolled out as we speak and offer (very) limited availability today. If you are looking for a low powered network for instant use, have a look at LoRa and/or Sigfox as discussed earlier, depending on your geographical location. While both are still under heavy development as well, they do already cover large parts of Europe and smaller parts of the US and Asia, to name just a few.
Cat 1 and Cat 0
LTE Cat 1 expands on the 4G portfolio (not offering the same features and/or benefits though, read on) and is currently the only full LTE based IoT standard available today, taking full advantage of the broad range and wide coverage LTE networks have to offer – fully standardized, as part of the 3GGP Release 8. While it doesn’t offer the same performance as 3G networks (that’s also why it was never seen as a relevant broadband service in Europe) it is an excellent fit for low bandwidth and browser based IoT applications. As the 3G technology is slowly being deprecated (also referred to as ‘sunsets’) world-wide, it is expected that Cat 1 will take its place instead. Think of Cat 1 as an early, potentially attractive alternative for IoT applications over LTE.
LTE Cat 0 is part of the 3GGP Release 12 and is considered to be the foundation for the earlier mentioned LTE-M standard. Different from Cat 1, Cat 0 has been designed with IoT in mind, as such it also offers lower data rates for both up and download aimed at power consumption, while at the same time making it cheaper because of this. Complexity, as opposed to Cat 1, has been reduced by over 50% by including only one receiver antenna and support for half-duplex operations. Where Cat 1 might take the place of 3G once it ‘sunsets’ LTE-M (with some help from Cat 0) will probably do the same for 2G in the (near) future.
Cheat sheet
Since the earlier published IoT networking technology cheat sheet contains a lot of additional (more technical) information, I’ve included it here as well. Read the accompanying blogpost for some more detailed information.
Future notes
Which technology or network type will prevail in the future is (very) hard to predict. In fact, there’s no real reason why they should be mutual exclusive, they don’t have to be. The fact that LTE networks have such a broad range globally and that they can also be used to provide NB-IOT and LTE-M networks with relative ease could oppose a threat to LPWAN networks. Especially when companies like Verizon and AT&T are the ones pushing the technology. Though the same can be said for LoRa as well, companies such as IBM and Cisco are showing immense interest, as are CSP’s like Swisscom and KPN.
On the other hand, with the LTE/cellular companies focussing on the high-end market, so to speak, and the LPWAN providers focussing on the lower to mid-market range, mainly in the form of sensor based data transport, there could be room for both. It also depends on in which part of the world or country (in some cases) you reside. If we look at Europe, the LPWAN networks are globally distributed already (LoRa in particular) while standards like NB-IOT and LTE-M and other closely related variants are still to be implemented. In the US and other parts of the world, it’s the direct opposite.
Other factors like, the rise of the 5G network (standards have yet to be defined – 2018), which is supposed to be operational for commercial use in 2020, or at least parts of it, the type of IoT devices and applications used, in terms of bandwidth and throughput, but also, capabilities around signal penetration and security might become more prominent going forward. In the end, it will all depend on the use-case at hand, since different network technologies will have different characteristics, the range of (I)IoT is too broad to fit ‘just’ one or two networks. Perhaps it’s not fair to say that every IoT application has its own unique requirements, but in some cases, a statement like this is not that far of.
All in all, lots of pros, cons and other consideration. If you haven’t done so already, make sure to check out parts one and two of this series as well, to get a complete picture.

Tuesday, March 20, 2018

OSM

OSM is delivering an open source Management and Orchestration (MANO) stack aligned with ETSI NFV Information Models. As an operator-led community, OSM is offering a production-quality open source MANO stack that meets the requirements of commercial NFV networks.

Ref:ETSI

Saturday, March 10, 2018

Network Slicing in 5G

5G is no longer something that is coming down the line, it is here and it will impact consumers and enterprises alike. In simple terms, 5G will be up to 100x faster than current 4G and 10x faster than the broadband connectivity that we are used to. With this speed the promise of other technology trends like IoT, AR, VR, Edge Computing and more really become possible.

One of the distinct key features of the 5G system architecture is network slicing. 4G supported certain aspects of this with the functionality for dedicated Core Networks. Compared to this 5G network slicing is a more powerful concept and includes the whole PLMN. Within the scope of the 3GPP 5G system architecture, a network slice refers to the set of 3GPP defined features and functionalities that together form a complete PLMN for providing services to UEs. Network slicing allows for controlled composition of a PLMN from the specified network functions with their specifics and provided services that are required for a specific usage scenario.
Earlier system architectures enabled what was typically a single deployment of a PLMN to provide all features, capabilities and services required for all wanted usage scenarios. Much of the capabilities and features provided by the single, common deployment was in fact required for only a subset of the PLMN’s users/UEs. Network slicing enables the network operator to deploy multiple, independent PLMNs where each is customized by instantiating only the features, capabilities and services required to satisfy the subset of the served users/UEs or a related business customer needs.
The very abstract representation below shows an example of a PLMN deploying four network slices. Each includes all that is necessary to form a complete PLMN. The two network slices for smartphones demonstrate that an operator may deploy multiple network slices with exactly the same system features, capabilities and services, but dedicated to different business segments and therefore each possibly providing different capacity for the number of UEs and data traffic. The other slices present that there can be the differentiation between network slices also by the provided system features, capabilities and services. The M2M network slice could, for example, offer UE battery power saving features unsuitable for smartphone slices, as those features imply latencies not acceptable for typical smart phone usages.
 The service-based architecture together with softwarization and virtualization provides the agility enabling an operator to respond to customer needs much more quickly. Dedicated and customized network slices can be deployed with the functions, features, availability and capacity as needed. Typically, such deployments will be based on a service level agreement. Further, an operator may benefit by applying virtualization, platforms and management infrastructure commonly for 3GPP-specific and for other network capabilities not defined by 3GPP, but that a network operator may need or want to deploy in his network or administrative domain. This allows for a flexible assignment of the same resources as needs and priorities change over time.
Deployments of both the smaller scope of the 3GPP defined functionality but also those of the larger scope of all that is deployed within an operator’s administrative domain are both commonly termed a “network”. Because of this ambiguity and as the term “slicing” is used in industry and academia for slicing of virtually any kind of (network) resources, it is important to emphasize that the 3GPP system architecture specifications define network slicing only within the scope of 3GPP specified resources, i.e. that what specifically composes a PLMN. This doesn’t hinder a PLMN network slice deployment from using e.g. sliced transport network resources. Please note, however, that the latter is fully independent of the scope of the 3GPP system architecture description. Pursuing the example further, PLMN slices can be deployed with as well as without sliced transport network resources.
The above figure presents more specifics of 3GPP network slicing. In that figure, network slice #3 is a straightforward deployment where all network functions serve a single network slice only. The figure also shows how a UE receives service from multiple network slices, #1 and #2. In such deployments, there are network functions in common for a set of slices, including the AMF and the related policy control (PCF) and network function services repository (NRF). This is because there is a single access control and mobility management instance per UE that is responsible for all services of a UE. The user plane services, specifically the data services, can be obtained via multiple, separate network slices. In the figure, slice #1 provides the UE with data services for Data Network #1, and slice #2 for Data Network #2. Those slices and the data services are independent of each other apart from interaction with common access and mobility control that applies for all services of the user/UE. This makes it possible to tailor each slice for e.g. different QoS data services or different application functions, all determined by means of the policy control framework.
Above discussion has highlighted one of the advancements of the 3GPP system architecture introduced with Phase 1 of 5G. Studies concerning Phase 2 of 5G will begin in the first quarter of 2018

References & specifications

  1. TS 23.501 – System Architecture for the 5G System; Stage 2
  2. TS 23.502 – Procedures for the 5G System; Stage 2
  3. TS 23.503 – Policy and Charging Control Framework for the 5G System; Stage 2