NCSA Brown Dog is a research project to develop a method for easily accessing historic research data stored in order to maintain the long-term viability of large bodies of scientific research. It is supported by the National Center for Supercomputing Applications (NCSA) that is funded by the National Science Foundation (NSF). == History == Brown Dog is part of the DataNet partners program funded by NSF in 2008. DataNet was conceived to address the increasingly digital and data-intensive nature of science, engineering and education. Brown Dog is part of a follow-on effort called Data Infrastructure Building Blocks (DIBBs), focused on building software to support DataNet. The project was proposed by researchers at NCSA and the University of Illinois Urbana-Champaign as well as researchers from Boston University and the University of North Carolina at Chapel Hill. == Unstructured, uncurated, long tail data == Much scientific data is smaller, unstructured and uncurated and thus not easily shared. Such data is sometimes referred to as "long tail" data. This borrows a term from statistics and refers to the tail of the distribution of project sizes. The majority of smaller projects lack the resources to properly steward the data they produce. This so-called "long tail" data, both past and present, has the potential to inform future research in many study areas. Much of this data has become inaccessible due to obsolete software and file formats. The resulting impossibility of reviewing data from older research disrupts the overall scientific research project. == Approach == Brown Dog describes itself as the "super mutt" of software (thus the name "Brown Dog"), serving as a low-level data infrastructure to interface digital data content across the internet. Its approach is to use every possible source of automated help (i.e., software) in existence in a robust and provenance-preserving manner to create a service that can deal with as much of this data as possible. The project sees the broader impact of its work in its potential to serve the general public as a sort of "DNS for data", with the goal of making all data and all file formats as accessible as webpages are today. == Technology == Brown Dog seeks to address problems involving the use of uncurated and unstructured data collections through the development of two services: the Data Access Proxy (DAP) to aid in the conversion of file formats and the Data Tilling Services (DTS) for the automatic extraction of metadata from file contents. Once developed, researchers and general public users will be able to download browser plugins and other tools from the Brown Dog tool catalog. === Data Tilling Service === Data Tilling Service (DTS) will allow users to search data collections using an existing file to discover other similar files in a collection. A DTS search field will be appended to configured browsers where example files can be dropped. This tells DTS to search all the files under a given URL for files similar to the dropped file. For example, while browsing an online image collection, a user could drop an image of three people into the search field, and the DTS would return all images in the collection that also contain three people. If DTS encounters a foreign file format, it will utilize DAP to make the file accessible. DTS also indexes the data and extract and appends metadata to files and collections enabling users to gain some sense of the type of data they are encountering. This service runs on port 9443. === Data Access Proxy === Data Access Proxy (DAP) allows users to access data files that would otherwise be unreadable. Similar to an internet gateway or Domain Name Service, the DAP configuration would be entered into a user's machine and browser settings. Data requests over HTTP would first be examined by DAP to determine if the native file format is readable on the client device. If not, DAP converts the file into the best available format readable by the client machine. Alternatively, the user could specify the desired format themselves. This service runs on port 8184. == Use cases == Brown Dog targets three use cases proposed by groups within the EarthCube research communities. Developers and researchers from these communities will work together on use cases that span geoscience, engineering, biology and social science. === Long tail vegetation data in ecology and global change biology === This use case is led by Michael Dietze, Boston University Data on the abundance, species composition, and size structure of vegetation is critically important for a wide array of sub-disciplines in ecology, conservation, natural resource management, and global change biology. However, addressing many of the pressing questions in these disciplines will require that terrestrial biosphere and hydrologic models are able to assimilate the large amount of long-tail data that exists but is largely inaccessible. The Brown Dog team in cooperation with researches from Dietze's lab will facilitate the capture of a huge body of smaller research-oriented vegetation data sets collected over many decades and historical vegetation data embedded in Public Land Survey data dating back to 1785. This data will be used as initial conditions for models, to make sense of other large data sets and for model calibration and validation. === Designing green infrastructure considering storm water and human requirements === This use case is led by Barbara Minsker], University of Illinois at Urbana-Champaign]; William Sullivan, University of Illinois at Urbana-Champaign; Arthur Schmidt, University of Illinois at Urbana-Champaign. This case study involves developing novel green infrastructure design criteria and models that integrate requirements for storm water management and ecosystem and human health and well being. To address the scientific and social problems associated with the design of green spaces, data accessibility and availability is a major challenge. This study will focus on identified areas of the Green Healthy Neighborhood Planning region within the City of Chicago where existing local sewer performance is most deficient and where changes in impervious area through green infrastructure would be beneficial to under served neighborhoods. Brown Dog will be used to extract long-tail experimental data on human landscape preferences and health impacts. This data will be used to develop a human health impacts model that will then be linked together with a terrestrial biosphere model and a storm water model using Brown Dog technology. === Development and application for critical zone studies === This use case is led by Praveen Kumar, University of Illinois at Urbana-Champaign Critical Zone (CZ) is the "skin" of the earth that extends from the treetops to the bedrock that is created by life processes working at scales from microbes to biomes. The Critical Zone supports all terrestrial living systems. Its upper part is the bio-mantle. This is where terrestrial biota live, reproduce, use and expend energy, and where their wastes and remains accumulate and decompose. It encompasses the soil, which acts as a geomembrane through which water and solutes, energy, gases, solids, and organisms interact with the atmosphere, biosphere, hydrosphere, and lithosphere. A variety of drivers affect this bio-dynamic zone, ranging from climate and deforestation to agriculture, grazing and human development. Understanding and predicting these effects is central to managing and sustaining vital ecosystem services such as soil fertility, water purification, and production of food resources, and, at larger scales, global carbon cycling and carbon sequestration. The CZ provides a unifying framework for integrating terrestrial surface and near-surface environments, and reflects an intricate web of biological and chemical processes and human impacts occurring at vastly different temporal and spatial scales. The nature of these data create significant challenges for inter-disciplinary studies of the CZ because integration of the variety and number of data products and models has been a barrier. On the other hand, CZ data provides an excellent opportunity for defining, testing and implementing Brown Dog technologies. In this context "unstructured" data is viewed broadly as consisting of a collection of heterogeneous data with formats that reflect temporal and disciplinary legacies, data from emerging low cost open hardware based sensors and embedded sensor networks that lack well defined metadata and sensor characteristics, as well as data that are available as maps, images and text. == NSF Award == CIF21 DIBBs: Brown Dog was awarded in the winter of 2013 with a start date of October 1, 2013. Estimated expiration date is September 30, 2018. The award amount was $10,519,716.00, the largest DIBB award. The principal investigator is Kenton McHenry of NCSA at the University of Illinois at Urbana-Champaign. Coleaders are Jong Lee NCSA/UIU
Zero-day vulnerability
A zero-day (also known as a 0-day) is a vulnerability or security hole in a computer system unknown to its developers or anyone capable of mitigating it. Until the vulnerability is remedied, threat actors can exploit it in a zero-day exploit, or zero-day attack. The term "zero-day" originally referred to the number of days since a new piece of software was released to the public, so "zero-day software" was obtained by hacking into a developer's computer before release. Eventually the term was applied to the vulnerabilities that allowed this hacking, and to the number of days that the vendor has had to fix them. Vendors who discover the vulnerability may create patches or advise workarounds to mitigate it, though users need to deploy that mitigation to eliminate the vulnerability in their systems. Zero-day attacks are severe threats. == Definition == Despite developers' goal of delivering a product that works entirely as intended, virtually all products contain software and hardware bugs. If a bug creates a security risk, it is called a vulnerability. Vulnerabilities vary in their ability to be exploited by malicious actors. Some are not usable at all, while others can be used to disrupt the device with a denial of service attack. The most dangerous allow the attacker to inject and run their own code, without the user being aware of it. Although the term "zero-day" initially referred to the time since the vendor had become aware of the vulnerability, zero-day vulnerabilities can also be defined as the subset of vulnerabilities for which no patch or other fix is available. A zero-day exploit is any exploit that takes advantage of such a vulnerability. == Exploits == An exploit is the delivery mechanism that takes advantage of the vulnerability to penetrate the target's systems, for such purposes as disrupting operations, installing malware, or exfiltrating data. Researchers Lillian Ablon and Andy Bogart write that "little is known about the true extent, use, benefit, and harm of zero-day exploits". Exploits based on zero-day vulnerabilities are considered more dangerous than those that take advantage of a known vulnerability. However, it is likely that most cyberattacks use known vulnerabilities, not zero-days. Governments of states are the primary users of zero-day exploits, not only because of the high cost of finding or buying vulnerabilities, but also the significant cost of writing the attack software. Nevertheless, anyone can use a vulnerability, and according to research by the RAND Corporation, "any serious attacker can always get an affordable zero-day for almost any target". Many targeted attacks and most advanced persistent threats rely on zero-day vulnerabilities. In 2017, the average time to develop an exploit from a zero-day vulnerability was estimated at 22 days. The difficulty of developing exploits has been increasing over time due to increased anti-exploitation features in popular software. === Window of vulnerability === Zero-day vulnerabilities are often classified as alive—meaning that there is no public knowledge of the vulnerability—and dead—the vulnerability has been disclosed, but not patched. If the software's maintainers are actively searching for vulnerabilities, it is a living vulnerability; such vulnerabilities in unmaintained software are called immortal. Zombie vulnerabilities can be exploited in older versions of the software but have been patched in newer versions. Even publicly known and zombie vulnerabilities are often exploitable for an extended period. Security patches can take months to develop, or may never be developed. A patch can have negative effects on the functionality of software and users may need to test the patch to confirm functionality and compatibility. Larger organizations may fail to identify and patch all dependencies, while smaller enterprises and personal users may not install patches. Research suggests that risk of cyberattack increases if the vulnerability is made publicly known or a patch is released. Cybercriminals can reverse engineer the patch to find the underlying vulnerability and develop exploits, often faster than users install the patch. According to research by RAND Corporation published in 2017, zero-day exploits remain usable for 6.9 years on average, although those purchased from a third party only remain usable for 1.4 years on average. The researchers were unable to determine if any particular platform or software (such as open-source software) had any relationship to the life expectancy of a zero-day vulnerability. Although the RAND researchers found that 5.7 percent of a stockpile of secret zero-day vulnerabilities will have been discovered by someone else within a year, another study found a higher overlap rate, as high as 10.8 percent to 21.9 percent per year. == Countermeasures == Because, by definition, there is no patch that can block a zero-day exploit, all systems employing the software or hardware with the vulnerability are at risk. This includes secure systems such as banks and governments that have all patches up to date. Security systems are designed around known vulnerabilities, and repeated exploitations of a zero-day exploit could continue undetected for an extended period of time. Although there have been many proposals for a system that is effective at detecting zero-day exploits, this remains an active area of research in 2023. Many organizations have adopted defense-in-depth tactics so that attacks are likely to require breaching multiple levels of security, which makes it more difficult to achieve. Conventional cybersecurity measures such as training and access control — including multi-factor authentication, least-privilege access, and air-gapping makes it harder to compromise systems with a zero-day exploit. Since writing perfectly secure software is impossible, some researchers argue that driving up the cost of exploits is considered a good strategy to reduce the burden of cyberattacks. == Market == Zero-day exploits can fetch millions of dollars. There are three main types of buyers: White: the vendor, or to third parties such as the Zero Day Initiative that disclose to the vendor. Often such disclosure is in exchange for a bug bounty. Not all companies respond positively to disclosures, as they can cause legal liability and operational overhead. It is not uncommon to receive cease-and-desist letters from software vendors after disclosing a vulnerability for free. Gray: the largest and most lucrative. Government or intelligence agencies buy zero-days and may use it in an attack, stockpile the vulnerability, or notify the vendor. The United States federal government is one of the largest buyers. As of 2013, the Five Eyes (United States, United Kingdom, Canada, Australia, and New Zealand) captured the plurality of the market and other significant purchasers included Russia, India, Brazil, Malaysia, Singapore, North Korea, and Iran. Middle Eastern countries were poised to become the biggest spenders. Black: organized crime, which typically prefers exploit software rather than just knowledge of a vulnerability. These users are more likely to employ "half-days" where a patch is already available. In 2015, the markets for government and crime were estimated at least ten times larger than the white market. Sellers are often hacker groups that seek out vulnerabilities in widely used software for financial reward. Some will only sell to certain buyers, while others will sell to anyone. White market sellers are more likely to be motivated by non pecuniary rewards such as recognition and intellectual challenge. Selling zero-day exploits is legal. Despite calls for more regulation, law professor Mailyn Fidler says there is little chance of an international agreement because key players such as Russia and Israel are not interested. The sellers and buyers that trade in zero-days tend to be secretive, relying on non-disclosure agreements and classified information laws to keep the exploits secret. If the vulnerability becomes known, it can be patched and its value consequently crashes. Because the market lacks transparency, it can be hard for parties to find a fair price. Sellers might not be paid if the vulnerability was disclosed before it was verified, or if the buyer declined to purchase it but used it anyway. With the proliferation of middlemen, sellers could never know to what use the exploits could be put. Buyers could not guarantee that the exploit was not sold to another party. Both buyers and sellers advertise on the dark web. Research published in 2022 based on maximum prices paid as quoted by a single exploit broker found a 44 percent annualized inflation rate in exploit pricing. Remote zero-click exploits could fetch the highest price, while those that require local access to the device are much cheaper. Vulnerabilities in widely used software are also more expensive. They estimated that around 400 to 1,500 people sold exploits to th
IP Multimedia Subsystem
The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is a standardized architectural framework for delivering IP-based multimedia services. Historically, mobile phones have provided voice call services over a circuit-switched network, rather than over an IP-based packet-switched network. Various VoIP technologies are available on smartphones; IMS offers a standardized protocol across different vendors. IMS was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), as a part of the vision for evolving mobile networks beyond GSM. Its original formulation (3GPP Rel-5) represented an approach for delivering Internet services over GPRS. This vision was later updated by 3GPP, 3GPP2 and ETSI TISPAN by requiring support of networks other than GPRS, such as Wireless LAN, CDMA2000 and fixed lines. IMS uses IETF protocols wherever possible, e.g., the Session Initiation Protocol (SIP). According to the 3GPP, IMS is not intended to standardize applications, but rather to aid the access of multimedia and voice applications from wireless and wireline terminals, i.e., to create a form of fixed-mobile convergence (FMC). This is done by having a horizontal control layer that isolates the access network from the service layer. From a logical architecture perspective, services need not have their own control functions, as the control layer is a common horizontal layer. However, in implementation this does not necessarily map into greater reduced cost and complexity. Alternative and overlapping technologies for access and provisioning of services across wired and wireless networks include combinations of Generic Access Network, softswitches and "naked" SIP. Since it is becoming increasingly easier to access content and contacts using mechanisms outside the control of traditional wireless/fixed operators, the interest of IMS is being challenged. Examples of global standards based on IMS are MMTel which is the basis for Voice over LTE (VoLTE), Wi-Fi Calling (VoWIFI), Video over LTE (ViLTE), SMS/MMS over WiFi and LTE, Unstructured Supplementary Service Data (USSD) over LTE, and Rich Communication Services (RCS), which is also known as joyn or Advanced Messaging, and now RCS is operator's implementation. RCS also further added Presence/EAB (enhanced address book) functionality. == History == IMS was defined by an industry forum called 3G.IP, formed in 1999. 3G.IP developed the initial IMS architecture, which was brought to the 3rd Generation Partnership Project (3GPP), as part of their standardization work for 3G mobile phone systems in UMTS networks. It first appeared in Release 5 (evolution from 2G to 3G networks), when SIP-based multimedia was added. Support for the older GSM and GPRS networks was also provided. 3GPP2 (a different organization from 3GPP) based their CDMA2000 Multimedia Domain (MMD) on 3GPP IMS, adding support for CDMA2000. 3GPP release 6 added interworking with WLAN, inter-operability between IMS using different IP-connectivity networks, routing group identities, multiple registration and forking, presence, speech recognition and speech-enabled services (Push to talk). 3GPP release 7 added support for fixed networks by working together with TISPAN release R1.1, the function of AGCF (access gateway control function) and PES (PSTN emulation service) are introduced to the wire-line network for the sake of inheritance of services which can be provided in PSTN network. AGCF works as a bridge interconnecting the IMS networks and the Megaco/H.248 networks. Megaco/H.248 networks offers the possibility to connect terminals of the old legacy networks to the new generation of networks based on IP networks. AGCF acts a SIP User agent towards the IMS and performs the role of P-CSCF. SIP User Agent functionality is included in the AGCF, and not on the customer device but in the network itself. Also added voice call continuity between circuit switching and packet switching domain (VCC), fixed broadband connection to the IMS, interworking with non-IMS networks, policy and charging control (PCC), emergency sessions. It also added SMS over IP. 3GPP release 8 added support for LTE / SAE, multimedia session continuity, enhanced emergency sessions, SMS over SGs and IMS centralized services. 3GPP release 9 added support for IMS emergency calls over GPRS and EPS, enhancements to multimedia telephony, IMS media plane security, enhancements to services centralization and continuity. 3GPP release 10 added support for inter device transfer, enhancements to the single radio voice call continuity (SRVCC), enhancements to IMS emergency sessions. 3GPP release 11 added USSD simulation service, network-provided location information for IMS, SMS submit and delivery without MSISDN in IMS, and overload control. Some operators opposed IMS because it was seen as complex and expensive. In response, a cut-down version of IMS—enough of IMS to support voice and SMS over the LTE network—was defined and standardized in 2010 as Voice over LTE (VoLTE). == Architecture == Each of the functions in the diagram is explained below. The IP multimedia core network subsystem is a collection of different functions, linked by standardized interfaces, which grouped form one IMS administrative network. A function is not a node (hardware box): An implementer is free to combine two functions in one node, or to split a single function into two or more nodes. Each node can also be present multiple times in a single network, for dimensioning, load balancing or organizational issues. === Access network === The user can connect to IMS in various ways, most of which use the standard IP. IMS terminals (such as mobile phones, personal digital assistants (PDAs) and computers) can register directly on IMS, even when they are roaming in another network or country (the visited network). The only requirement is that they can use IP and run SIP user agents. Fixed access (e.g., digital subscriber line (DSL), cable modems, Ethernet, FTTx), mobile access (e.g. 5G NR, LTE, W-CDMA, CDMA2000, GSM, GPRS) and wireless access (e.g., WLAN, WiMAX) are all supported. Other phone systems like plain old telephone service (POTS—the old analogue telephones), H.323 and non IMS-compatible systems, are supported through gateways. === Core network === HSS – Home subscriber server: The home subscriber server (HSS), or user profile server function (UPSF), is a master user database that supports the IMS network entities that actually handle calls. It contains the subscription-related information (subscriber profiles), performs authentication and authorization of the user, and can provide information about the subscriber's location and IP information. It is similar to the GSM home location register (HLR) and Authentication centre (AuC). A subscriber location function (SLF) is needed to map user addresses when multiple HSSs are used. User identities: Various identities may be associated with IMS: IP multimedia private identity (IMPI), IP multimedia public identity (IMPU), globally routable user agent URI (GRUU), wildcarded public user identity. Both IMPI and IMPU are not phone numbers or other series of digits, but uniform resource identifier (URIs), that can be digits (a Tel URI, such as tel:+1-555-123-4567) or alphanumeric identifiers (a SIP URI, such as sip:[email protected] ). IP Multimedia Private Identity: The IP Multimedia Private Identity (IMPI) is a unique permanently allocated global identity assigned by the home network operator. It has the form of a Network Access Identifier(NAI) i.e. user.name@domain, and is used, for example, for Registration, Authorization, Administration, and Accounting purposes. Every IMS user shall have one IMPI. IP Multimedia Public Identity: The IP Multimedia Public Identity (IMPU) is used by any user for requesting communications to other users (e.g. this might be included on a business card). Also known as Address of Record (AOR). There can be multiple IMPU per IMPI. The IMPU can also be shared with another phone, so that both can be reached with the same identity (for example, a single phone-number for an entire family). Globally Routable User Agent URI: Globally Routable User Agent URI (GRUU) is an identity that identifies a unique combination of IMPU and UE instance. There are two types of GRUU: Public-GRUU (P-GRUU) and Temporary GRUU (T-GRUU). P-GRUU reveal the IMPU and are very long lived. T-GRUU do not reveal the IMPU and are valid until the contact is explicitly de-registered or the current registration expires Wildcarded Public User Identity: A wildcarded Public User Identity expresses a set of IMPU grouped together. The HSS subscriber database contains the IMPU, IMPI, IMSI, MSISDN, subscriber service profiles, service triggers, and other information. ==== Call Session Control Function (CSCF) ==== Several roles of SIP servers or proxies, collectively called Call Session Control Function (CSCF), are used to process SIP sign
Single address space operating system
In computer science, a single address space operating system (or SASOS) is an operating system that provides only one globally shared address space for all processes. In a single address space operating system, numerically identical (virtual memory) logical addresses in different processes all refer to exactly the same byte of data. In a traditional OS with private per-process address space, memory protection is based on address space boundaries ("address space isolation"). Single address-space operating systems make translation and protection orthogonal, which in no way weakens protection. The core advantage is that pointers (i.e. memory references) have global validity, meaning their meaning is independent of the process using it. This allows sharing pointer-connected data structures across processes, and making them persistent, i.e. storing them on backup store. Some processor architectures have direct support for protection independent of translation. On such architectures, a SASOS may be able to perform context switches faster than a traditional OS. Such architectures include Itanium, and Version 5 of the Arm architecture, as well as capability architectures such as CHERI. A SASOS should not be confused with a flat memory model, which provides no address translation and generally no memory protection. In contrast, a SASOS makes protection orthogonal to translation: it may be possible to name a data item (i.e. know its virtual address) while not being able to access it. SASOS projects using hardware-based protection include the following: Angel IBM i (formerly called OS/400) Iguana at NICTA, Australia Mungi at NICTA, Australia Nemesis Opal Scout Sombrero Related are OSes that provide protection through language-level type safety: Br1X Genera JX a research Java OS Phantom OS Singularity Theseus OS Torsion
Electric Literature
Electric Literature is an American literary magazine. == History == Founded by Andy Hunter and Scott Lindenbaum in 2009 as a print quarterly journal, Electric Literature transitioned to a daily website in 2012 under the helm of Halimah Marcus and Benjamin Samuel. Electric Literature publishes essays, reading lists, interviews, fiction, poetry, graphic narratives, humor, and book news, all available to read online for free without a paywall. It launched the first fiction magazine on the iPhone and iPad. Work published has been recognized by Best American Short Stories, Essays, Poetry, and Comics, the Pushcart Prize, Best Canadian Short Stories, The Best of the Small Presses, and the O. Henry Prize. in 2014, Electric Literature became a registered non-profit. In 2016, Halimah Marcus was appointed the first executive director of Electric Literature. She has been with the magazine since 2010. In 2021, Denne Michele Norris became editor-in-chief of Electric Literature, the first Black and openly trans editor-in-chief of a major U.S. literary publication. In 2022, Electric Literature was the Digital Prize Winner of the Whiting Literary Magazine Prizes. In 2023, Electric Literature partnered with Banned Books USA to offer free banned and challenged books to residents of Florida. In 2025, Electric Literature published their first book, edited by Norris and published by HarperOne: Both/And: Essays by Trans and Gender-Nonconforming Writers of Color. It builds on a prior essay series that Electric Literature sponsored for trans writers of color. Both/And became a finalist for the 2026 Lambda Literary Award for Transgender Nonfiction. == Recommended reading == In May 2012, Electric Literature launched Recommended Reading, a weekly fiction magazine. Each issue is curated by a well known editor or writer. == The Commuter == The Commuter, a weekly magazine for poetry, flash, graphic, or experimental narrative, debuted in January 2018, helmed by writer Kelly Luce.
Network Abstraction Layer
The Network Abstraction Layer (NAL) is a part of the H.264/AVC and HEVC video coding standards. The main goal of the NAL is the provision of a "network-friendly" video representation addressing "conversational" (video telephony) and "non conversational" (storage, broadcast, or streaming) applications. NAL has achieved a significant improvement in application flexibility relative to prior video coding standards. == Introduction == An increasing number of services and growing popularity of high definition TV are creating greater needs for higher coding efficiency. Moreover, other transmission media such as cable modem, xDSL, or UMTS offer much lower data rates than broadcast channels, and enhanced coding efficiency can enable the transmission of more video channels or higher quality video representations within existing digital transmission capacities. Video coding for telecommunication applications has diversified from ISDN and T1/E1 service to embrace PSTN, mobile wireless networks, and LAN/Internet network delivery. Throughout this evolution, continued efforts have been made to maximize coding efficiency while dealing with the diversification of network types and their characteristic formatting and loss/error robustness requirements. The H.264/AVC and HEVC standards are designed for technical solutions including areas like broadcasting (over cable, satellite, cable modem, DSL, terrestrial, etc.) interactive or serial storage on optical and magnetic devices, conversational services, video-on-demand or multimedia streaming, multimedia messaging services, etc. Moreover, new applications may be deployed over existing and future networks. This raises the question about how to handle this variety of applications and networks. To address this need for flexibility and customizability, the design covers a NAL that formats the Video Coding Layer (VCL) representation of the video and provides header information in a manner appropriate for conveyance by a variety of transport layers or storage media. The NAL is designed in order to provide "network friendliness" to enable simple and effective customization of the use of VCL for a broad variety of systems. The NAL facilitates the ability to map VCL data to transport layers such as: RTP/IP for any kind of real-time wire-line and wireless Internet services. File formats, e.g., ISO MP4 for storage and MMS. H.32X for wireline and wireless conversational services. MPEG-2 systems for broadcasting services, etc. The full degree of customization of the video content to fit the needs of each particular application is outside the scope of the video coding standardization effort, but the design of the NAL anticipates a variety of such mappings. Some key concepts of the NAL are NAL units, byte stream, and packet formats uses of NAL units, parameter sets, and access units. A short description of these concepts is given below. == NAL units == The coded video data is organized into NAL units, each of which is effectively a packet that contains an integer number of bytes. The first byte of each H.264/AVC NAL unit is a header byte that contains an indication of the type of data in the NAL unit. For HEVC the header was extended to two bytes. All the remaining bytes contain payload data of the type indicated by the header. The NAL unit structure definition specifies a generic format for use in both packet-oriented and bitstream-oriented transport systems, and a series of NAL units generated by an encoder is referred to as a NAL unit stream. == NAL Units in Byte-Stream Format Use == Some systems require delivery of the entire or partial NAL unit stream as an ordered stream of bytes or bits within which the locations of NAL unit boundaries need to be identifiable from patterns within the coded data itself. For use in such systems, the H.264/AVC and HEVC specifications define a byte stream format. In the byte stream format, each NAL unit is prefixed by a specific pattern of three bytes called a start code prefix. The boundaries of the NAL unit can then be identified by searching the coded data for the unique start code prefix pattern. The use of emulation prevention bytes guarantees that start code prefixes are unique identifiers of the start of a new NAL unit. A small amount of additional data (one byte per video picture) is also added to allow decoders that operate in systems that provide streams of bits without alignment to byte boundaries to recover the necessary alignment from the data in the stream. Additional data can also be inserted in the byte stream format that allows expansion of the amount of data to be sent and can aid in achieving more rapid byte alignment recovery, if desired. == NAL Units in Packet-Transport System Use == In other systems (e.g., IP/RTP systems), the coded data is carried in packets that are framed by the system transport protocol, and identification of the boundaries of NAL units within the packets can be established without use of start code prefix patterns. In such systems, the inclusion of start code prefixes in the data would be a waste of data carrying capacity, so instead the NAL units can be carried in data packets without start code prefixes. == VCL and Non-VCL NAL Units == NAL units are classified into VCL and non-VCL NAL units. VCL NAL units contain the data that represents the values of the samples in the video pictures. Non-VCL NAL units contain any associated additional information such as parameter sets (important header data that can apply to a large number of VCL NAL units) and supplemental enhancement information (timing information and other supplemental data that may enhance usability of the decoded video signal but are not necessary for decoding the values of the samples in the video pictures). == Parameter Sets == A parameter set contains shared configuration data that is carried in non-VCL NAL units. Parameter sets are typically reused when decoding many coded pictures within a video sequence. Each VCL NAL unit references a picture parameter set (PPS), which in turn references a sequence parameter set (SPS). There are two types of parameter sets: Sequence parameter set (SPS), which specifies mostly constant configuration such as resolution, bit depth, or chroma format. (For a concrete implementation, see FFmpeg's SPS struct.) Picture parameter set (PPS), which applies on top of an SPS, and specifies configuration such as QP offsets. (For a concrete implementation, see FFmpeg's PPS struct.) The sequence and picture parameter-set mechanism decouples the transmission of infrequently changing information from the transmission of coded representations of the values of the samples in the video pictures. Each VCL NAL unit contains an identifier that refers to the content of the relevant picture parameter set and each picture parameter set contains an identifier that refers to the content of the relevant sequence parameter set. In this manner, a small amount of data (the identifier) can be used to refer to a larger amount of information (the parameter set) without repeating that information within each VCL NAL unit. Sequence and picture parameter sets can be sent well ahead of the VCL NAL units that they apply to, and can be repeated to provide robustness against data loss. In some applications, parameter sets may be sent within the channel that carries the VCL NAL units (termed "in-band" transmission). In other applications, it can be advantageous to convey the parameter sets "out-of-band" using a more reliable transport mechanism than the video channel itself. == Access Units == A set of NAL units in a specified form is referred to as an access unit. The decoding of each access unit results in one decoded picture. Each access unit contains a set of VCL NAL units that together compose a primary coded picture. It may also be prefixed with an access unit delimiter to aid in locating the start of the access unit. Some supplemental enhancement information containing data such as picture timing information may also precede the primary coded picture. The primary coded picture consists of a set of VCL NAL units consisting of slices or slice data partitions that represent the samples of the video picture. Following the primary coded picture may be some additional VCL NAL units that contain redundant representations of areas of the same video picture. These are referred to as redundant coded pictures, and are available for use by a decoder in recovering from loss or corruption of the data in the primary coded pictures. Decoders are not required to decode redundant coded pictures if they are present. Finally, if the coded picture is the last picture of a coded video sequence (a sequence of pictures that is independently decodable and uses only one sequence parameter set), an end of sequence NAL unit may be present to indicate the end of the sequence; and if the coded picture is the last coded picture in the entire NAL unit stream, an end of stream NAL unit may be present to
Mixvoip
Mixvoip S.A. is a Luxembourg-based telecommunications service provider founded in 2008. The company offers IP telephony, high-speed Internet connectivity, and IT solutions to businesses and individuals. == Company history == In November 2017, Mixvoip expanded its operations to Belgium and Germany. At the beginning of 2019, the company acquired the telecommunications provider Voipgate. In December 2019, Mixvoip was named Telecom Company of the Year at the Luxembourg ICT Awards 2019 organized by Farvest and IT One. A 2024 article in Duke described the company's transition during the 2010s from traditional telephony services to cloud-based communication platforms. In the end of 2024, the ILR published the statistics about electronic communications in Luxembourg, including Mixvoip in the fix telephony section. In July 2025, Mixvoip acquired Crossing Telecom. In 2026, Mixvoip acquired Nomado's portfolio.